DOCDilBNT EBSOME 



ED 125 533. 



IB 003 617 



AOTHOP. 
TITLE 

INSrriTOTION 

SPONS AGENCY 
•aZPORT NO 
POB DATE 
GEANT 
NOTE 

EDES PEICE 
DESCEIPTOES 



IEENTIFI2BS 



Marcus^ Richapd S.; Reintjes^ J. Francis 

The Nqtvorkiixg of Interactive Bibliographic Retrieval 

Systems. 

Massachusetts Inst, of lech.^ Cambridge. Electronic 
Systems Lab. 

National Science Foundation , Washington^ D .C . 

ttIT-ESI-R-656 

Mar 76 

NSF-SIS74-18165 
172p. 

MF-50.83 HC-$8.69 Plus Postage. 

Computer Prog rams j Computer Science; ^Information 
Retrieval; Information Science; *Netwcrks; *0d Line 
Systems ; Program Descriptions ; *Research Projects 
CONIT ; *Connector for Networked Information 
Transfer 



ABSTRACT 

Research in networking of heterogeneous in^teractive 
bibliographic retrieval systems is being conducted which centers on 
th€^ concept of a virtual retrieval system. Sa^h a virtual system 
would be created through a translating computer interface that would 
provide acc'ess to the different retrieval systems and data bases in a 
uniform and convenient way^ even for the inexperienced user . An 
experimental interface^ called CONIT, has been built to test tW' 
virtual system concept. Initial evaluation of CONIT, which connects 
four retrieval systems, suggests that the virtual system approach 
could be cost effective. Particular attention was focused on the 
requirements f cr a common command language,' ease of use, and message 
interpretation and protocols in a networked' interface. (Author/JY) 



Documents acquired by ERIC include many informal unpublished 
materials not available from other sources. ERIC taakes ever-y effort 
to olDtain the best copy available. Nevertheless, it^ms of marginal 
reproducibility are often encountered and this affects the quality 
of the microfiche and hardcopy reproductions ERIC makes available 
vie the ERIC Document Reproduction" Service (EDRS) . EDES is not 
responsible for tlie qiaality of the original document. Reproductions 
supplied by EDES are the best that can be made from the original. 



********************************************************** 



ERIC 



March 31, 19 76 



Reoort ESL-P-656 



LjJ 



I * ' TE CT I \T 5 1 B L I C G F A ? ^' I C ?£ T ? I rT/ A L S Y ST S 



by 

^chard S. Marcus 
J. Francis Peintjes 



The research supported herein was made possible through the 
supported extended by the National Science Foundation through 
"Grant NSF-SIS-74-18165 , 



us OEPAHTMEHT OF HEALTH. 
E0UC*T10H»<''ELF*«E 
HATIOHAL INSTITUTE OF 
EOUCATIOH 

TH.S DOCOMENT H»5 
DU^ED EXACTLY »S RECEIVED "OM 
?«E PERSON OR ORGANIZATION ORIGIN. 
It «g't POINTS 0.= VIEW OR OPINIONS 
STATED DO NOT NECESSARILY RE"E- 
^;Of.= lC..L NATIONAL INSTI TUTE OP 
EDurATiON POSITION OR POLICY 



ERIC 



k5 
CO 

o 



Electronic Systems Laboratory 
Department of Electrical Engineering and Computer Science 
Massachusetts Institute of Technology 
Cambridge^ Massachusetts 02139 



ABSTRACT 

Research irr-tha networking of heterogeneous interactive biblio- 
graphic retrieval systerrs has been continued, The concept of a virtual, 
retrieval systerr has been studied. Such a virtual 'system would be created 
through a translating coirputer interface that would provide access to the 
different retrieval systems and data bases in a uniform and convenient 
way, even for the inexperienced user. An experimental interface, called 
CCr:iT, has been built to test the virtual systerr. concept. Initial evalu- 
aticn of ^or:iT,' whicr. connects four retrieval systers, suggests that the 
virtual syster approach could be cost effective. Particular attention was 
focused on the requirements for a cormn conrpand language, ease«>of -use , 
and message interpretation and protocols in a networked intei-face, . 



3 



* 



ACKT^OVfLEDGEMEITT 



This report constitutes the final report for Grant NSF-SIS-74-18165 , 
entitled "Research in the Coupling of Interactive Information Systems." . 
The project was supported by the Division of Science Information of the 
National Science Foundation and covered the period July^ 15, 1974 through 
November 31, 1975. 

We wish to acknowledge the cooperation extended to us by the 
National Library of Medicine, the^ Lockheed Corporation, and the Systems 
Develcprent Corporation in conjunction with our use of their respective 
online retrieval systeirs. 

v;e acknowledge the efforts of Mr. .Joseph J, Passaf i'ume, Staff 
Merber in cur research groyp, who, since ^>re' joined the^' pro ject, has made 
a major contribution in the area of computer programjr.ina. and systems^ 
analysis as related to networking. 



ii 



CONTENTS 

INTRODUCTION 

1.1 The Developing Informatioa Transfer Scene 

1.2 Status of Computer Resource Sharing 

1.3 Problems of Utilization of Retrieval^Systems 

1.4 The Ip.terface Approach to Connecti^ig Systems 

1.5 Outline cf v;ork and^ Report^ 

C0:;IT: THE EXPERiyJTNTAL INTERFACE 

2.1 Instructional Features 

2.2 System Selection, Connection, and Detaching 

2.3 Response Translation 

2.4 General Retrieval Comirand Translation 

2.4.1 Database Selection 

2.4.2 Search Cortupan^s 

2.4.3 Index Browsing Command 

2.4.4 Naming and Combining Retr^ieved Sets 

2.4.5 OutpuVs:ommands 

2.4.6 Saving Output 

2.4.7 News and Status of Retrieval Systems 

2.5 Systejas Analyst Functions 

2.5.1 Translation Tables . 

2.5.2 Dialog Modes and Language 

2.5.3 CONIT Status Reporting 



2.5.4 System and TIP-I'ort Connection and Detaching 

2.5.5 Connecting and Disconnecting CONIT 



USER/SYStEK INTERACTION: GENERAL PRINCIPLES 

3.1 Importance of the User/System Interface 

3.2 Clas^ses of Users 

3.3 Instruction: Computer-Assisted and Other 

3.4 Computer Techniques That Aid Learning 



A COMMON LANGUAGE 'FOR RETRIEVAL 

4.1 English as a Common Language 

4.1.1 Advantages and Disadvantages of English 

4.1.2 The Ambiguity Problem 

4.1.3 Elements of English that are Desirable and Practical 

4.2 Desired Structure and Features of ,Interactive Languages 

4.3 Specific Plans for a Retrieval Language/Protocol 

4.3.1 General -Considerations J 

4.3.2 Retrieval Language Structure 

4.3.2.1 Commands/Arguments/Delimiters 

4.3.2.2 End of Message Signal 
,4.3.2.3 Command Terminator 
4.3.2.4 Bracketing 

4.3.3 Dialog Control 

4.3.3.1 Input Editing 

4.3.3.2 Interrupting 

4.3.3.3 User Prompts and Status 

4.3.3.4 VERBOSE, TERSE, and Other SPEAK modes 

4.3.3.5 Renaming , ^ , 

4.3.4 System and Data'Base Selection and Connection 

4.3.5 Search and Related Functions 

4.3.5.1 Basic and Other Search Aspects 

4.3.5.2 Selection of Data Bases, Files, and Search 
Elements 

,^.3.5.3 Term Selection, ' Combinations, and Matching 
4.3.5.4 Results: Naming, Combining, and Re-searching 

4.3.6 Ou^ut and Related Functions 

4.3.7 Instruction and Status Review 

4.3.8 Saving, Sharing', and Reviewing Results 



Page 

41 

41 

41 

43 

47 

49 

54^ 

54 

57 

57 

58 

58 

58 

59 

59 

59 

60 

62. 

64 

65 

•67 ^ 

*67 

68 

70 
74 
78 
81 
83 



4.4 Summary 



84 



iv 



6 



5. r-ESSAGE INTERPRETATION AND PROTOCOLS IN AN INTERFACE 

5.1 Simple Model 

5.2 Limitations of Simple ilodel 

5.2.1 Interface/Systems Dialog Unmediated by User 

5.2.2 Indefinite Nature of Systems Response 

5.2.3 Unexpected or Unpredictable Messages 

5.2.4 Overlapping of Messages 

5.2.5 Multiple Simultaneous Retrieval Systems 

5.3 A More Comprehensive Characterization 

5.3.1 Communicants and Communications 

5.3.2 Communicants as Rule-Governed Processes 

5.3.3 Structure and Timing Considerations 

5.3.4 Message-Handling Rules for the Interface 

5.3.5 Message Formats, Timing, and Segments 

5.3.6 Rule-Matching Criteria 

5.4 Retrieval Protocols in Cooperating Networks 

6. EVALUATIOt^S 

6.1 Physical Interconnections 

6.2 Effectiveness of Interface Approach 

6.2.1 The Dimensions of Effectiveness 

6.2.2 The Common Retrieval Language 

6.2.3 The Master Index and Thesaurus 

6'. 2.4 Common Bibliographic Data Structure 
6.2.5 Costs and Benefits 

6.3 Logical Interconnections 

6.4 Areas Requiring Further Work 
6.5. Conclusions 

'7. PROtJECT BIBLIOGRAPHY • . ' ' 



Pa^e 

86 

86 
89 
89 • 
90 
91 

^^-^ 

93 
93 
94 
96 
98 
99 
' 102 
103 

110 

110 
110 
110 
' 112 
114 
115 
116 
^ 117 
1X9 
. 121 

■■123 



8. REFERENCES 



124 



7 * 



APPENDIX A. Sample User/CONIT Dialog 

B. CONIT Instructional Messages 

C. CONIT Translation Tables , 

D. Suggested User Protocols for Access to a Computer 
via a Network 



Page 

128 
148 
152 
159 



LIST OF FIGUllfiS 

1. Logical Diagram of Virtual-System Interface 

2. Sampled Relationships among Terns as Maintained in Master Index 
Thesaurus 



3. Comiron Bibliographic Data Elements and Structure for the Indexing 
Category 

4. Computer Interconnections for CONIT Experimental Interface 

5. Logical Structure of User Statement 

6. Time Diagram of User/System Message Flow for Simple Sequential 
Operations ' i 

7. Time Diagram of Message Flow with Interface Process for Simple 
Sequential Operation \ 

. B. • Time Diagram of 'Typical Message Flow for General Interface - 
. Situation , ^ 

9. Model of Message Interpretation .and Pesponse Components in 
Interface 

10. Diagram of Retrieval Network in which Interface is Distributed 
in User and Server Programs 

^ #» 

11. Schematic Diagrams Qf Server Components - 



Pa ge , 

lo' 

12 
13 

19 

53 
88 

88 

'97 

100 
106 
108 



ERiC 



V.1 



8 I- 



1. 'INTRODUCTION 



1.1 The Developing Information Transfer ^ene 

^ *. 1,2 

In th^ preceding 10 years there has been a rapid development 

in techniques for achieving trarlsfer of information among individuals 
representing a ^common community of interest, such as in a scientific 
discipline or technical Many of these new techniques have 

centered on, and depended upon, the rapidly growing technology of 
the digital computer, especially in its online, interactive, time-shared 
and networked aspects. Thus we have seen the growth from experimental, 
to prototype, to operational stages of online computer-based systems 
that provide rapid simultaneous access, for dozens of users on widely- 
distributed terminals, to information in data bases containing up to 

6 9 
10 or more records with 10 or more characters. 

For the coming 10 years we can predict with a fairly high degree 
of confidence that this trend toward systems of increasing capability 
will continue/ Of course, one aspect of this growth will likely be an 
increased capacity Tor these information 'syst^ems in terms of number 
and size of data bases and the number of simultaneous online users. 
Another aspect of development will undoubtedly be reduced cost; while 
the exponential increase in capabilities for a given cost in such com* 
puter system components as CPU, storage, peripherals, and data trans- 
mission that has marked the past 10 years cannot be expected to con- 
tinue indefinitely, there is no indication tha,t the rate of improve- ^ 
ment for these cost factors will slacken in the near future. A third 
aspect of development that can be predicted 'with 3ome degree of assur- 
ance for interactive information systems is improved computer-assisted 
instructional capabilities that will make these systems easier to 
ledrn and' use by the ave^^age, non-computer-specialist user. A fourth 
area of development for these systems will likely be thfeir continued 
refinement in terms of impi^oved functional capabilities within the 
functional areas of the individual classes of systems: thus for ex- 
ample, retrieval system^ may be expected to have more flexible search 
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and output capabilities. 

The fifth and, perhaps, most challenging area for development 

I 

in the near future is one that might be given the dual heading of net- 
working and integration. Integration refers to bringing together for 
a user the many diverse _information transfer functions. Besides 
bibliographic information retrieval — where systems are now well de- 
veloped for retrieval 'of references to documents — there are now, at 
least m an experimental stag^, many other capabilities/ such as 
computer techniques for storing and retrieving numerical data and full- 
text alphanumeric infoo^ation, alerting users on a periodic basis to 
new information that has entered a data base which is relevant to their 
profile of interest (selective dissemination of information — SDI) , 
identifying persons who can help answer questions and, generally, 
facilitating interpersonal communication. Other potentials for com- 
puterized informil^ion transfer services include techniques that facilitate 
"publication" (perhaps, entirely in an-electronic medium), enable process- 
ing of retrieved information of all types and, finally, techniques that 
actually enable the answering of general questions posed in natural 
language or other formats and presentation of the answers in whatever 
format is most effective. Examples of various forms of presentation 
include natural language, numerical, graphic, oral, or combination^ 
of th*ese. 

Systems of the far future may ultimately incorporate all these 
functions into one master information tjfansfer system. ^ The possibility 
of such a master system is one area for current research. Howeyer, 
for the near and 'intermediate future — say, the next 10 or 20 years, 
it is likely that there will continue to exist separate systems for 
at least some of these functions. Therefore, enhanced user access 
to these separate systems through computer interfaces is another vital 
area that needs substantial attention at present. j 

Such interfaces are possible only in a computer network environ- 
ment. Such an environment^ if designed adequately, ^>ermits the inter- 
connection of different systems. It also permits the interconnection 

10 j 
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/ 

of different components of the same system, so as to make effective use 
of distributed computer-system components* The ability to do resource- 
sharing in a distributed computer network may well, then, be the key 
not only to increased effectiveness through' functional- integration 
but also to increased economy through efficient utilization of system 
components. The overall status of the general area qf, computer resource- 
sharing will be described next, 

1.2 Status of Computer Resource-Sharing 

The sharing of hardware -a?id software resources in a single co 



e com- 
ing ^ 



puter has been accomplished through the development of time-sharin 

3^ 

systems like those pioneered at M.I.T.'s Project MAC and elsewhere. 
With suitable digital communication links, such systems can extend re- 
source sharing by providing access to users at remote locations over 
dedicated or switched telephone channels, A variety of systems soft- 
ware and hardware enables a user to select any prograin^in the system. 
This program, m turn, can call on other programs to perform computation, 
transfer of data into or out of the system, arid other kinds of processing. 
In the time-sharing environment users and programs can share^^l^hese 
computer resources simultaneously. 

Generally speaking, each computer program to be used ij^r this kind 
of shared, environment must be carefully designed to fit into the specific 
operating environment of a given computer and, in particular, its input/ ^ 
output characteristics must be well known to any using programs. Where 
these preconditions of cooperation and compatibility hold, the extension 
of the concepts of sharing to multiple computer systems and their as- 
sociated resources is quite possible, although, of course, not without 
the resolution of substantial technical questions. However, a partic- 
ularly vexing situation arises i^n the common case where one must con- 
tend with computer systems that have been independently and heterogeneously 
designed. 

A partial solution to^the problem of sharing resources from 
independent computer^ is found in terms of those telecommuni cations 

-3- ^ - 
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networks which interconnect user terminals to differe^'t computers. One 
such network is that of the Tymshare Corporation (called Ti}/\^T^^Ji^\jhLch^ 



interconnects users from a variety of terminals thTough "satellite" mini- 
computers to a dozen or more different computer systems. Networks of 
this type provide enhanced access tgA^ultiple, heterogeneous computer 
•systems in that they enable terjrtinals having different character sets 
and speeds to call a local telephone number (in mos^t metropolitan U,S. > 
areas and some foreign areas) and get connected^ to widely dispersed \ 

and different computer systems. Thus, access is made easier in that a ' 

* 

the user does not have to contend with niultiple telephone numbers and 
terminal connectio/i protocols. Also, communications cost is lower in 
such a network than for separate direct-dialed or even leased-line ^ 
connections, especially for the casual or infrequfent user. 

' It should be. noted, honever, -that te rminal access per se is 
just one component of the process of Sharing use of multiple, hetero- 
geneous computer systems. At least two other ipomponfentis miist be' present 
for the effective sharing of he^terogeneous computer resources. One is 
the ability of different, computers and prograrps within the computers 
to transfer data to each other. A second needed component is the ability 
for either a program or human to make convenient and effectiv,6* use of 
the various facilities ortce access itself is^ attained. In this regard , 
it is desirable that existing ^srogr^ms and systems be usable as building 
blocks for other programs and systems. 

The interconnection of and transfer of -data among heterogeneous 
computers — including those having different manufacturers as well as 
differing operating systems — has been an activity undergoing vigorous 

development in recent years. Several regional computer networks that 

5 ^ ' * 

can be mentioned as examples of this development are: the Michigan 

Educational Research Information Triad (MERIT) , the Triangle Universities 

Computation Center of North Carolina (TUCC) , 'and the State of Georgia 

University System Computation Network. Perheips the most well-known 

computer network currently in operation is t/iat of the* Advanced Research 

12 ' . 
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Agency (ARPANET).^ ^ ARPANET is the prime representative of a class of 
networks featuring packet-switching technology. A commerical version 
of the ARPANET, call Telenet.^ and developed by the^Telenet Communications 
Corpoi^ation, has recently become operational. These networks provide 
the necessary uniformity and/or compatibility through hardware and 
software interfaces and ■cammunica.tion channels and protocols so that 
data transfer and process control are enabled among the computers and 
programs . 

, Providing convenient access to the facilities within these net- 
works has iDeen^'the goal of a series of developments involving satellite 
minicomputers analogous in function to those ^ntioned above for the 
TYMNET network but attempting 'to provide more extensive and flexible 
capabilities. Many of >these" developments^ have been directly involved 
with improving access to ARPANET facilities. These include (1) the 
ARPANET Terminal Inte^faqe Message Processor (TIP) developed by Bolt, 
Beranek/ and Newman, Inc.; (2) the ARPA NetWork Terminal System (ANTS) 

developed at , the Universt^y^ Illinois ; (3) the ELF "front end" system"^^ 

* * 
develbped- by the Speech Communications Research Laboratory; and (4) the 

"l^etwork Access Machine" (NAM) developed at the National Bureau of 
11 

Standards . 

In addition to these attempts at providing more convenient access / 
many other developments have been taJcing placq which seek to provide 
more effective means for the separately create|d and distributed computer ^ 
programs to communicate with each other using |:he basic dat^ transfer '"^^ 
protocols ^o as to integrate ^for users the cap< 



"resources. A few ^examples- may be giveji to indi 



developments\ Crotker et al ^^Jexplained how plrotocola.-Texis t at differ-- 



ilities of dis;p42rged • 
cate the trenj^- of these 



are used by higher- 
itives are more closely 



ent levels ; low-level *communicati(§)ns protocols 
level, "function-oriented" protocols whose prima 
related to the substantive functions users require. Some examples of 
high-level protocols that^^ have been developed ^or ARPANET use include 
(1)^ the TELNET ^ pro toc51 *Sy which a usjer at a terminal controls a process 
in a remote host computer as if he were a local user of that host; (2) 
a File TRA^ISF^R Protocol for transfering "raw" text 'files* (means to 

13 ^ 



transfer structured files are^ currently under development); and (3) a 
Remote Job Entry (RJE) protocol. 

Another major development . in resource sharing has been the bringing 
together in one system of several different functions which get executed 

-» 

by invoking previously created programs on different computers. Such a 

13 

system is the Resource Sharing Executive (RSEXEC) developed at Bolt, 

* 

Beranek, and Newman, Inc. RSEXEC is a distributed, executiVe-like' system 
that enables ARPANET users to obta^fi, using, a common command language, 
various services from different ARPftNi^T host computers such as providing 
status information sending messages and performing certain ' file-maintenance 
operations. A second example is found in a current project of the Ad- 
vanced Research Projects Agency called t^e National Software Works ' 
(NSW) . The purpose of NSW is to bf ing together within one system the 
means to 'generate and test computer programs so that, for example, a 
program can be written using an edit program on one computer, combined" 
on a second computer, and run on still a third computer. 

1.3 Problems of Utilization of Retrieval Systems 

One area in whi^;h a .sharing and interconnecting of computer., 
facilities would be particularly useful is that of interactive biblio- 
graphic retrieval systems. It is in this area that the research reported 

15 < • 

on here has concentrated. As McCam has pointed out, uses of these 

f • * ' 

systems have increased significantly in recent years. This appli- 
cation is thus starting to fulfill its early promise as one of the im- 
portant applications to be served by the gi'owing field of computer-based 
time-shared systems. Tens of thousands of searches are performed monthly 
by a number of different systems which have access, in the aggregate, 
to dozens of data ^ases containing, in total, more than five million 
references to documents of many different types-*— e.g., books, reports, 
journal and news articles, etc. — in a wide range of- subject areas 
in science, technology, and the arts. There has been a steady rise in 
t^eSe statistics over the last few years as ne^^stems and data bases 
^ave. come online and mor<^ and more ilfsers* have le^bd^ of their existence 
and retrieval effectiveness. ^ ^ 
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The very success of these systems has tended to aggravate the 
problem of convenient use because of the difficulties faced 'by users 'in 
learning how to interact with the multiplicity of heterogeneous systems 
and data bases. A potential user of different retrieval systems is 
'faced with a series of obstacles right from the start: the necessity 
to discover these systems in the first place, to enter into separate 
procedures to gain access and reimburse costis, and possibly — if the 
systems are not interconnected through a common network, as described 
above ~ to make actual access via different terminals and separate 
locations, other obstacles face the user once the initial access' is 
made: different commands* languages , retrieval functions, indexing 
vocab.ularies, and output formats. Even within a given system, -access 
to different data bases is often frustrated by th% differences in 
catalog record fields and indexing methods tl^at the system may only 
partially compensate for. .It is little wonder then, that currently 
access to these systems is primiarly through a professional intermediary — 
a specially trained librarian, for exaitple, rather than by the user him- 
self. 

It might be thoqght that a single system and database should ^ 

satisfy a given user. It has been our experience at M.I.T. with the 

16 17 ' ^ 

Intrex and NASIC systems, however, that a single user generally 

needs access to many different bases, if not for a given search, then 
over a period of time as his needs change. Furthermore, in a community 
of professionals with heterogeneous interests, access to a multiplicity 
of resources pert"aining to several disciplines is required. These 
resources are better stored as separate data bases rather than aggregated 
into a single huge data base. 

These differences present substantial difficulties even to 
experienced users. In the NASIC at M.'l.T. program ; yhere librarians 
have been trained as information specia'lists to assist end users in 
teearching "online data bases, we have found that several weeks of train- 
ing' and continuing practice at the terminal were needed by the specialists 

-7- 
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to get to a high level of proficiency and to maintain th^t level. A 
significant part of the learning difficulty was cause^d by the differences 
among data bases and systems. Even the specialists have found it de- 
sirable to specialize in a small number of data bases and, sometimes, 
in only one or two systems, at least partly for the reason of the 
heterogeneity of data bases and systems. Another reason, of course, 
is that existing systems have not yet realized the full potential of 
computer-assisted instruction. 

In a study of current users of online bibliographic retrieval 

systems performed by the Systems Development Corporation under sponsor- 

18 

ship from the National Science Foundation it has been reported t\x^t 
a sampling of users surveyed by questionnaire indicated in the main 
that they were not having *'major" difficulties in using different 
systems and data bases. Howevex, over half of respondents did report 
"some" difficulty and the users surveyed constitute a biased sample 
in that they have already spent the effort to master the various 
systems and tend to be the heavy, intermediary-type users who would 
have less difficulty maintaining competence. Also, the results of this 
study are based largely onijsers* own evaluations without correlation 
with how well the user is operating the systems. In any^case, a fuller 
evaluation of these recent results needs to be performed to see if it 
really is at variance with the more generally-accepted notions of 
difficulty as expressed above. , ' 

The end user i^ay not have to master as many data bases and 
systems a^s the specialist searcher, but this contraction is more than 
offset by the fact that, in general, the end user has neither the time 
nor the inclination ' for training or practice. In fact, it is for 
this reason NASIC and others have decided that it is unrealistic in 
the present information-retrieval environment to expect end users 
to do their own searches, especially when the computer time — as well 
as the user's time^ — is such a costly commodity. 
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1.4 The Interface Approach to Connecting Systems 

In order to investigate means to surmount the obstacles hinder- 
ing convenient and effective use of the multiplicity of heterogeneous 
interactive retrieval systems, the M.I.T. Electronic Systems Laboratory 
has undertaken a research program to examine the feasibility of inter- • 
connecting interactive retrieval systems thrd^h computer interfaces. 
The computer interface would achieve compatibility among systems of 
heterogeneous hardware and software components through use of, or trans- 
lation to and from, common retrieval protocols. (See Fig. 1.) 

19 

From Its early stages our research program has emphasisled an 
approach in which the interface is, in effect, a common system into 
which and fror which requests and results are translated automatically 
as they flow bet^-^een user and serving systems. This approach has^ the 
virtue that a user attempting to retrieve information, when entering I 
through the access mechanism provided by the common interface, sees 
a "single virtual system in which all the complexities of the different 
retrieval systems and data bases are hidden and only a single uniform 
system is apparent. In this way the goal of convenient use of h^tero- 
^geneolis computer resources 'is achieved, at least for the particular - ' \ 
application of interactive bibliographic retrieval systems. Two aspects 
of our approach that characterize our attempts at the application of 
networking are (1) the use of existing, major, stand-^lone interactive 
systems without modification ; and (2) an emphasis on serving, the 
ordinary end user — that is, a user experienced neither in coirputer 
programi^ing , general computer usage nor in the use of interactive 

retrieval systems, in particular. 

. • . . '19 ^ 

Our initial analysis of the requirements for a c0inmon inter^* 

face pointed to the need for three main kinds of logical components for 

an effective virtual bibliographic retrieval system: a common command 

language, a means for converting among indexing vocabularies and a common 

bibliographic data structure. Our review of these coinponents, and of 

techniques likely to be useful in their implementation, is summarized below. 
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The Common Command Language 

The common language should be a language in which all the func- 
tions for information retrieval operations can be conveniently expressed 
by users. One goal of such a language is to break the functions into 
the smallest components that find any different application in any two 
systems so that any function in any language can be expressed as a 
combination of common language functions, i.e., a macro function in 



the common language. 



Indexing Vocabulary Conversion V ""'^-^ ^ - 

We believe that a good basis for ah^ intermediary language for ' 
indexing vocabularies is 'natural English. This is accomplished through 
a mechanism wfe have dubbebv^he Master Index and Thesaurus which contains 
the index and thesaurus elemeh4^ of each of the data bases, including 
an ordered list of all vocabulary^rms usfed for indexing together 
with the counts of the nu/pher of docurnents indexed by each and the 
thesaurus relations tor each. (See Fig. 2.) In addition, through use 
of the techniques of phrase decomposition (that is, breaking a phrase 
down into its individual words) and stemming (dropping word endings 
so as to consider only the word stems) we can automatically identify 
most intervocabulary relationships . . \ 

A Coi3||^on Bibliographic Data Structure 

A common bibliographic structure can be based on the identifi- 
cation of data primitives or basic data elements, analogous to the 
basic component fvnctions of the common command language. Data ele- 
ments in any system can then be translated into, or composed from, 
combinations of basic data elements in the comni6n^data structure. The 
basic data elements would be hierarchically arranged into a data struc- 
ture and, typically, the data element of a system would be equated to a 
higher-level node of the common data structure. An exanple of part of 
such a structure for data elements that relate to document contents 
and indexing is shown in Fig. 3. 



19 

-11- 



1.4 



AWn72 




elecfric fields 



T,N 



<f > 



c-lecfric insulating paDersJ'.^ [J . 



elecfric sporks 



electrical insolafion 




I 

RT 
I 
I 



electrical insulators 



T ^ 



msul 



afors 



N 



-o ation 
--e qHng 



T,N 



thermal insulalion 



• NT - 
-BT 1 



capacitor paper 



asbestos 



N 



dielectrics^ 



UF 



T,N 
wiring ' 



nonconductors 



N 



electrical porcelain^ 





KEY 




relationship established automatically * 




relationship'taken from existing thesaurus 


T 


DOD TEST THESAURUS 


N 


NASA THESAURUS 


RT • 


RELATED TERM 


NT 


NARROWER TERM 


BT 


BROADER TERM 


UF 


USED FOR 


U 


USE 



FIGURE 2 SAMPLE RELATIONSHIP AMONG TERMS AS MAINTAINED IN 
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These and other aspects of the interface — including how to 
fit the interface into the developing network framework will be 
discussed in* the body of this report... 

1.5 Outline of Wo^rk and Report 

In this sectiqn we outline the contents of the remainder of the 

/ 

report and, in doing so, summarize the nature of the work that has been 
undertaken on the project, especially tliat portion that has been 
accomplished under the current grant during the past 16 months. 

In Section 2 •we describe the experimental ititerface that has 
been constructed on the M.I.T. MULTICS system in order to te^t the 
concepts and techniques developed in the theoretical conponent of our 
research program. At the beginning of this grant period we had a simpli- 
fied experimental interface that connected to two retrieval systems 
containing about 8 data bases; a very simple translation of two 
commands — a search and an output* command — was provided. During 
the present grant period the interface was extended to include con- 
nection to four retrieval systems with a total of about 50 data basj^s* 
Most of the foundations for a common command language was provided 
with ^ a generally adequate translation to the four systems. A number 
of changes^were -made to the interface to impro\(e the automat icityv and 
reliability of establishing and maintaining cormections to the 
different systems. In ^ition, a modest degree of translation of 
system responses to a common^format was achieved and the beginnings 
of an instructional mode were implemented. In general, the experi- 

iftental interface has now, reached that point of development in which 

)' 

several (knowledgeable) users have been able to try it^out for both^ 
demonstration and initial evaluatic^ purposes. 

I In Section 3 .of this reporrt we* list knd explain those general 

principl^ for user/system interaction for 'online systems which serve . 



as^^quideilines for our research program. MSly of these guidelines had ^ 
been developed by us and others prior to o'ur ciirrent network effort 
but additional factors specifically relatitig to networking ^nd to an 
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interface/virtual system were discovered and integrated into the gen- 
eral principles. 

Section 4 includes a discussion of the general principles that 
could serve as a basis for the development of a common command language 
for interactive information systems and specific suggestions for the 
development of such a language. The advisability of using natural English 
as a command language for the interface is discussed. Here again, while 
the general principles for command languages- have previously received 
considerable study, our work has extended them and applied them to 
the interface situation. We have tried to go beyond simply describing 
languages in the direction of prescribing optimized forms and explain- 
ing the reasons ,for the choices made. 

In Section 5 we discuss the necessary elements for successful 
interprocess message communication among systems and human users in 
the interface situation. A model based on such investigations can 
serve three functions:' (1) provide a basis for explaining some of the 
iitportant features of interprocess communication in the general human/ 
computer interactions and in the interface situation in particular; 

(2) provide a mechanism for detailing the actual interpretation 

and translation functions to be 'performed in specific situations; and 

(3) serve as. a framework for software modules that ^ ould execute the 
interpretation and translation functions in a flexible, tabl-e-driven 
manner. Section 5 also contains discussion of how a common Retrieval 
protocol might be relevant to the interface situation. 

The experimental interface is described first in this report 
in order to make more concrete several elements of our work^ However^ 
the reader might well choose to concentrate on some or all of the 
analytic Sections 3 through 5, before Section^, if he so chooses. 

Section 6 gives our evaluation of the woirk to date. This in- 
cludes a discussion of cost and benefits •for interface systems of 
varying degrees of sophistication.' Several side-benefits to work 
in the interface area are also described » Section 6 also discusses 
-futvre work that could prove beneficial in the interface field. 

References, and appendices follow in the remainding 'sections ♦ 
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2. C(>IIT: THE EXPERIMENTAL INTERFACE 

We have constructed an experimental interface on the M.I.T. 
MULTICS computrer system in order to test concepts and techniques developed 
in the theoretical component of our research. We call this interface 
CONIT, an acronym standing for; COnnector for Networked ^Information Trans-' 
fer. In this section we sha^ll describe CONIT in some detail so as to 
provide a concrete base oti which the theoretical and evaluative studies 
of the later sections can be more readily understood. That is, in this 
section we describe what CONIT is; in later sections*' we explain wh^ it 
is the way it is and how a better interface might differ from it. 

It should be emphasized that CONIT is an experimental system and, 

as such, no attempt has been made thus far to provide a compreh^ensive 

interface. Rather it has been constructed so as to be able to test 

specific, representative functions and techniques. There are ways ..in 
* K 

which CONIT caa be easily extended to cover more functions; other ex- 
tensions would be more difficult. The nature of these extensions and 
their respective importance and difficulties will be discussed in this, 
and later sections. ^ 

We shall first describe (Sections 2.1 - 2,4) how CONIT appears to 
the ordinary user, namely a person who might be using the interface to 
retrieve information for his own use from the networked retrieval systems 
and their data bases. Some indication of the software and hardwcire that, 
underlie the interface will also be given. Later (Section 2.5), we shall 
describe the special features of the system \&iich enhance its operation 
from the points of view of the analyst and designer. 



2..i Instructional Features 



Let us start at the point aj^-ivhich the CONIT system itself has 
bee^/^alled. (The initial conj>^tion and logging in to MULTICS and 
calling CONIT presents some special considerations that we shall discuss 
later in Section 2.5.5). Upon entering CONIT the user is made aware 
that instructions on how to use CONIT are available. The initial message 
(see appendix A) te-lls the 'user that he may go ahead and use CONIT if 
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he knows how or, otherwise, it tells how he may get instructional in- 
formation, 

* / 

^. In this first-level of contputer-assisted instruction th^r user 

has one basic command, EXPLAIN, by which to request instruction. The* 
EXPLAIN comman(^ has the syntax*: ' 

* explain concept 

where the one argument, concept, is the name of a concept — or a mnemonic" 
abbreviation for the concept that CONIT is being asked to explain to 
the user. The concepts that can be explained are ^related to each 'other' 
in a hierarchical fashion: the explanations for the general conpepts 
list the names of more detailed concepts. The currently available ex- 
planations are shown in Appendix B. At the highest level is the con- 
cept explain which can be invoked by the command^ *expl,ain explain'** 
or by the simple synooym 'help* . ^ ' , • 

The command 'sp^k. terse' will cause €ONIT to abbreviate its 
dialog with the user. The command 'speak verbose' causes CONIT to re- 
turn to the normal, lengthly dialog providing extensive instruction^ 

2 ^2 System Selection, Connection and Detaching 

The most elaborate command, in terms of the mechanisms required ' 
within CONIT to implement it, is the PICK command by which the user can 
request cohnection to a retrieval ^system and ^n-pick a data base in ^ 
which to search* There are five systems to which CONIT, currently makes 
a connection: (1) The M.L.T. Intrex system resident on an IBM 370/168 
under TSO in Cambridge, Massachusetts; (2) the Lockheed DIALOG system 
on an IBM 360/50 in Palo Alto, California ; (3) the System Development 



*In this report we shall use underlining in examples of langtJj^ge con- 
structions to irfaicate variable elements, 

**In this 'report we shall use sirtgle quotes to bracket a ''character 
string that qould be used in the command language; the two outermost 
delimiting single quotes are not part of the string itself., 
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Corporation (SDC) ORBIT systenvon an IBM 370/158 in Santa Monica, ^ 
California; and (4) the National Library of Medicine (NLM) MEDLINE 
sj^stem fcr which there are two implementations , to which we can. connect: 
one on a 370/158 machine at the NLM Bethesda; Maryland headquarters 
(referred to as NLM/MEDLINE) and , one on a similar machine^ at the State 
University of New York at Albany (referred to as ♦ SUNY /MEDLINE) . CONIT 
currently supports a virtual-system type interface to these five systems; 
these five systems and several Other systems can also be connected in 
.a "transp^rei^t" mode, a5 will be .explained below, * *. \ 

There are different modes- of physical interconnection to these 
five systems^ and these differences are reflected in tiie operations of 



he PICK coifimand'. These physical interconnections have been previously 

described '^^ ^ one mode of interconnection as shown in Fig. 4 is ^ 

through the ARPANET TIP at the National, Bureau of Standards to the NLM 

MEDLINE system in Bethesda. • The other mode of interconnection requires 

a "patch"-t>^e , manUally-set connection between two manually-dialed 

phone lines: one between a Boston-area TIP and the patch box and a 

second between the patch box and a c6mputer having access to one or more 

retrieval systems. This latter, computer can be the M.I.T. 370 with 

the Intrex system or it can be a local TYMNET satellite computer which 

provides connection to the Lockheed, SDC, and the two MEDLINE systems 

through "the TYMNET -network.. The NBS TIP/MEDLINE ^connection is generally 

maintained whenever the NLM/MEDLINE system is available. The patch 

connections are made on an ad hoc basis as needed for the experiments. 

Note that hoth that NBS TIP and the patch connections can* be used at the • 

same time so that two retrieval systems can be connectioned simultaneously. 

Also, we fully recognize that these low-bandwidth^ terminal-oriented 

connections are far inferior to higher-bandwidth, 'inter-computer ^ri^ented 

telecommunications that we would prefer (see Section 6.1) ; however, they 

have proved sufficient to carry out our initial experiments on the 

higher-level aspects of the coupling of information retrieval systems. 

Uo select a system the CONIT usep types 

• . / ' ' ^ > 

pick system 

2G ■ 
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where system is the name of the system. CONIT performs a numbel: of 
functions in executing the PICK command (see appendix A for examples) : 

^ (1) Oieck to see if system is a valid system 

(2) Check to see if system is already connected 

(3) If system involves a TYMNET connection and there 
is a system already connected through TYMNET, 
then log the first system out. (The logoff pro- 
tocol may involve the interchange of several • 
messages to and from the first system) 

(4) If there already is a system connected but it is 
connected through a TIP other than the one needed 
for the requested system connection, put the current 
system in a connected-but-not-active status and 
proceed to connect the second system. 

(5) Establish a connection to the appropriate ARPANET^ 
TIP port if not already made. (This may require 
cycling through a niomber of TIP ports to find one 
that is available.) 

(6) If system refers to TYMNET system, follow the 
appropriate TYMNET protocol to call up that system. 

(7) Login by following the appropriate protocol. (This 
r may include a separate call to the retrieval system 

after login; e.g., for NLM/MEDLINE) . 

(8) Answer any initial system questions (e.g., "Do you 
want experienced-or new-user mode?" — CONIT works 
in experienced-user mode for compactness.) ' 

When the appropriate response is not seen by CONIT (e.g., 
because pf system failure or unavailability) in following one of the 
above protocols, CONIT returns control to the user with an ^indication 
of what the problem is. This indication may currently be of the most 
general kind (e.g., "proper response not seen") and may ox may not lea\ 
the user in a position to continue to reselect another system. 

2 . 3 Response Translation 

As in all cases where response from a retrieval system is 
received by CONIT, there is a translation of retrieval system response 

2b • • . 
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into a form more suitable to the user of the interface. There are two 
main mechanisms for implementing this translation. The first is a simple 
string-for-string translation table. The response message stream is 
scanned to see if any character strings match the "left-hand" or "input" 
or "argument" side of entries in the table. For each rfi'atch found the 
matched string in the response stream" is replaced by the "right-hand" 
or "output" cr "function" side string of the matched entry in the trans- 
lation tables. A separate translation table is* active, for each retrieval 
system connected to. See Appendix C for listing of translation tables. 
One function currently performed by these tables, for example, iS to 
translate the string "PROG:", meaning in the ORBIT language that the 
message following is coming from the retrieval system, into the name of 
that retrieval system: whether SDC/ORBIT or NLM/MEDLINE or SUNY/MEDLINE 
the latter two MEDLINE systems being basically implemented in the same 
ORBIT framework as for the SDC system. 

The second mechanism for response translation is simply the 
general one of the appropriate code within €he routines that handle 
the dialog with the ' retrieval systems. For example, one function of 

these routines is to determine when any response is completed by looking 

♦ 

for a specific "end-of-message" string, which is usually the "user prompt" 
i.e., "<NL>USER:<NL>" for Intrex; ("<NL>" stands for a new-line cKaracter 
or carriage return.) These system-specific u^er prompts are replaced 
by the CONIT common prompt "<NL>USER: :<NL>" — or simply "::" in TERSe 
mode. Many of the translations of both the table and the general 
routine mechanisms are, currently, simply to suppress a portion of 
the response (e.g., a system telephone number or the whole dialog, about 
new or experienced users) or to pass along the message without modi- 
fication to the user (e.g. , broadcast news during login.) 

2.4 • General- Retrieval Command .Translation * T-*^* 

The retrieval functions that can be performed 'through tONIT 
in the network of retrieval systems, besides the logging 'in and logging 
out described above, are largely accomplished, currently, through simple 
ti^anslations from the prototype common command language to the languages 
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of the individual retrieval systems through the mechanism of translation 
tables. These "user command" tables work in a fashion similar to the 
response translation tables. The command or request message stream 
as generated by the user is scanned, and any part of the stream that 
matches any entry in the command translation table for the system that 
is currently connected is biodified by replacing the matched segment 
wLth the corresponding right-hand side of the table entry. This 
translated command is then sent to the retrieval system. 

2.4.1 Data Selection 

The CONIT user can find out what data bases are available in 
the currently connected system by using the command 'show data.' This 
gets translated to the commands *?FILES' in DIALOG and '"FILES?* in 
the ORBIT systems. No translation, as such, is made for Intrex but 
the mechanism is provided for such a request to evoke ai\ instructional 
message explaining that Intrex has only one data base.* 

In the ORBIT systems, unlike DIALOG, not all data bases are 
available at the same time. The '"FILE?' command explains what data 
bases a*re available at the moment. To request a listing of all data 
bases that a system can make available at one time or another the 
CONIT command "show data all" is employed. This gets translated to 

4 

•"EXPLAIN SCHED' for SDC OI^IT, '""FILES' for NLM/MEDLINE and '"FILES' 
for SUNY/MEDLINE. Note the small but crucial differences in the trans- 
lations for 'show data [alll' even among the nominally identical ORBIT 
systems. Also note that the ordering of the rules iS' important; by 
insisting~on a "longest-match-first" order 'show data all' tal^s pre- . 
cedence over 'show data' which takes precedence, in turn, oveir^ 'show'* 
(see Section 2.4.5). 

The command 'pick data database ' is used to select a data 
base. The^ atring 'pick data' is replace by the string '.FILE' for 
DIALOG and '"FILE' for ORBIT systems. (Actually, the additional 
function '"USERS"' is added to the MEDLINE systems translations and 
'"TIME"' to'^the SDC/ORBIT translation both in order to make them some- 
what more compatible with the DIALOG^ translation . The argument database r 
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which signifies the nanve of the data iDase' to be connected, is left un- 
translated for the ORBIT systems. For DIALOG a translation is made from 
a mnemonic name to the number required by DIALOr,: thus, for example, 
the strings 'eric' and 'ntis' are converted to the numerals '1' and '6', 
respectively. Of course, a user could use the appropriate numbers, if 
he knew them, and they would get transmitted to DIALOG without conversion. 

The data base selection command takes precedence over system 
selection because the translations are executed before CONIT looks 
for comm.ands it should execute rather than transmit. Commands to ORBIT 
systems initially required sending a final double quote ('") and con- 
verting all lower-case letters to upper ca^e. With recent modifications 
* to these systems these requirements are no longer necessary. 

2.4.2 Search Commands 

The basic common search command ' f ijnd term' is translated '"FIND 
ALL term ' 'select term' and 'subject term' lin ORBIT, DIALOG, and Intrex , 

respectively. The 'ALL' argument to ORBIT indicates that all alternate 

I 

meanings of the terms term are to be^ assumed desired instead of re- 
questing the user to select some or all of these alternates. This 
translation is more in keeping with the intended meaning of the FIND 
command default option for the common command language. Actually, only 
'the Intrex translation provides the automatic phrase decon^osition and 
stemming that we wish to basic research mechanism to provide. (See^' 
Section 4 for additional details). 

The more 'spe,cific command to search for a particular author 'find 
author name' can be readily translated into DIALOG as * select au= name ' 
and Intrex as 'author name ' but the translation ko ORBIT '"FIND name 
(AU)"' is not possible with the current ranslatioi^ table mechanism be- 
cause of the required rearrangement of the ordering;^ of the ^author' and 
'name' arguments. In the actual translation to ORB^^T we use, '"FIND 
name', will work satisfactorily as long as the given \author name is not 
also a subject index term.- ' \ 

The symbol is the CONIT designation that, when appended to a 
character-string argument to FIND ~ viz., 'magnet+', iridicates a match 
should be made on any terfn exactly the same as the» given string (e.g., 
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'nagnet') or any tern haying that string as a prefix (fe.g., 'magnet*, 
'magnetic*, ' nagnetization ' , etc. This gets translated to the corres- 
ponding ORBIT symbol ' : ' or DIALOG symbol '?'. Intrex cannot handle 
this user-supplied stem; it takes words in the user-given terms and 
automatically tries to find the best stem to search under according 
to Its stemming algorithm. 

One could conceive of Boolean operations among the terms of a 
FIMD command. The systems to which CONIT connect, however, are so 
'Iissimilar- in t^heir capabilities m this respect that CONIT currently 
rakes only a mnor attempt to take advantage of the potentialities in 
a comjT-ion way. Intrex ignores all Booleans in the search command and 
relies on its Boolean ANDING of stemmed words; CONIT now does nothing 
to change a Boolean pperator intended for Intrex, though' it perhaps 
should, at least, issue a warning to any unwary user who tries to use 
an OR or NOT. ORBIT does allow a general Boolean qapability within 
the search (FIND) command and these operators are passed along by CONIT 
to ORBIT as found. DIALOG does not pr9vide for Booleans, as such,' with 
its search (SELECT) statement; it does, however^, provide some powejrful 
"link" type operators for its "free-text" searching and one of these 
(F) , as^ in 'term A (F) term B' , meaning term A must occur in the same 
field as term B — is taken as a reasonable Equivalent for the CONIT 
AND operator. 

The different kinds of search operations possible in the different 
systems, and the different manner of indexing for the different data 
bases m the different systems (or, even, within a single system) point 
up the inherent* difficulty - and, often, impossibility — of exact 
translation from a common language to existing retrieval systems and 
data bases. 

2.4.3 Index Browsing Command 

The CONIT command ' show index term ' i^s^ intended to provide a 
display of terms alphabetically near to term in the index to the current 
data base. The translation is to the NEIGHBOR command for ORBIT and 
Eyjpmu for DIALOG. (Intrex has no equivalent command.) As can be seei^ 
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fron the response and command translation tables an atten^t is made by 
CONlf to make a common protocol for continuation of the index browsing 
function after the first display is made (5 terms for ORBIT, 15 for 
DIALOG). Thus "UP N OR DO^-TN N?" in ORBIT and the laconic "-more*" 
in DIALOG are both converted to "To see more type 'show more'.". 
Correspondingly, the CONIT 'show more' command^" is translated to the 
'COV7N 5' command for ORBIT' and '0' (page) command for DIAbOG which 
both have tne effect of requesting a second section of index term dis-' 
-lay equal m length to the first and continuing v;here it left off. 

We r.ay note, parenthetically, the difficulty of making these 
protocols exactly equivalent even for the simple case or length of 
initial section: either multiple corrnands would have to be sent to 
ORBIT and sections spliced together or the DIALOG response would have 
to be buffered and read out in sub-sections.^ This complexity would be 
compounded if we trier* to incorporate the full capability of the 
ORBIT command with respect to a variable number of terms -in either the 
forward (alphabetically) or backward directions, 

we may note, also, that the full capability of DI^^LOG to tag 
these displayed 'terms (with "E and R numkerjs")^ and use only the short 
tags in the FIND (SELECT) command is implicitly available. The selection 
of multiple terms in this ^ay is an implicit Boolean OR function. ORBIT 
does not have this capability; although, it could be implemented at the 
interface level at some programming expense. 

2.4.4 Naming and Combining Retrieval Sets 

The CONIT convention is to name the set of documents resulting 
ftom a search in the form: 'setn', wh-ere ^ is a number assigned 
sequentially for each new search set. This contrasts with the convention 
of using just a sequential number of ORBIT and DIALOG and the form 'sn' 
used by Intrex. 

The CONIT language expression for combining sets takes the form: 

\ 

combine set nl bool setn2 
where bool stands for one of the Boolean operations AND, O-R^ and AND NOT. 
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Tr.e conversion of this form to the appropriate retrieval system language 
IS shown in the tables. r-Jote that ORBIT and Intrex do not use an ex- 
plicit corJeand for the combine operation but rather use only the Boolean 
operator itself to indicate the function to be performed; therefore 
for these two systems, the translation for 'combine* is null. 

2.4.5 Output Commands 

To have CONIT display information about documents in some re- 
trieval set the basic SHOV; command is employed with the following syntax* 

show [mode] [setn] [fields] [docsj_-y 

where, 

(1) the variable argument mode stands for some special node 
of output, e'.g., offline. 

(2) set£ specifies a retrieval set 

(3) fields is an argum.ent string containing one or more 
data fields or field groups to be output; e.g., title, 
abstract, all 

(4) The arg:ument docsj_-k specifies that output is t(? be 
derived from the catalog records of the j^^ through 
the kth documents in the search set. 

We note again that particular features of several of the retrieval 
systems prevent a perfect translation to th4 several systems within fehe 
limitations of the current CONIT translation mechanism. Some examples 
of these di,f f iculties may be instructive to the general problem of 
interface translations. Firstly, there may be no way of outputting some 
catalog data field for a given data base as ^implemented on a particular 
system. For example, the DIALOG system provides only a half-dozen or 
so. fixed-groupings of fields for output purposes. For most DIALOG data 



bases, then, one cannot select for output just the author or just the 



title, or 3ust title and author, for exai^ple. The current t^^anslations 
simply make reasonable approximations. Thus, * title' is translated 
to DIALOG output, code 6 which includes the title and, variously, other 
citation information like order number, price, authors/ etc. The^ default 



♦elements in brackets indicate optional terms: they need not, in general, 
hfi included — in which case they ar"^ supplied 'default* values by CONIT, 
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case (i.e.v no data fields specified) is equated with the DIALOG code 
2 'output which is nominally citation information but often contains 
considerably more than ^tjtat (e.g., index terms) — in some sense there 
would be a closer translation to DIALOG 'title' category output, but 
getting the same result for title and citation output might cause con-' 
fusion to a user. Note that even in these sitnple translations CONIT 
users can avoid the necessity to separate field names with commas as 
required by ORBIT. 

The argument 'all' in CONIT is meant to indicate output of all 
fields is desired. This function has traditionally been performed by 
the argument 'FULL' in ORBIT. However, with the addition of abstracts 
to certain NLM and SUNY data bases (e.g., MEDLINE, SDILI^TE ) this function 
is now performed by the argument "DETAILED'. VJe ;r,ay also 'have the 
situation in which the same function must be e>:pressed differently in two 
data bases, even within the same system. Also, note, how changes in the 
systems cause a translation to become incorrect. 

Secondly, only ^ the DIALOG system can provide the document 
selection function directly in the form given in the 'docsj-k' argument. 
A translation to ORBIT can readily be done when j=l, but the more general 
case requires the argument string 'm SKIP rv' , where m = k-j+1 and 
n = j-1. COMIT cannot , perform this more general translation with its 
simple translation tables. Intrex cannot perform this document selection 
f\inction within its ou,tput /command. It can, however, perform the 
overall function by filtst creating a. set of just those documents 
question. Thus, the string Df two commands 




docs jj-k/ouput 

wil'l perform \he desired output. The problem is that the simple trans- 
lation table mechanism cannot rearrange the fixed element 'docs' and 
'output' and inaert the variable elements ' j^-k^' between them., 

When no argument is given by a user to specify the set' it is 
^ assumed in the common CONIT language that the current (i.e., last-found) 
set is desired. The translation is implicit to ORBIT and Intrex which 
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have the same default arrangement. The translation to QJALOG is not 
now possible since that system has no default mode ,fo3r the argument 
and CONIT does not yet have a way to xemember the current set number. 
• If no set number is given for DIALOG, CONIT now simply assumes setl. 

Where an interrupt capability is available to the user it is 
anticipated that any good common Language (see Section 4) will make 
the default condition on the document selection argument (docs j-k) 
of the output command be the whole set the user interrupting when 
he's seen enough. At present CONIT simply adopts the default procedure 
for the target ir system — for ORBIT: the first 5 documents; for DIALOG: 
the first document (or first 5 for tit/e only); for Intrex: the whole 
set. • 

In the ultimate common language the order of the arguments should 
be largely immatenial. ^Vhere this is true in the current IR systems 
(e.g., ORBIT and Intrex), the ^^urrent CONIT language can ^accept that 
flexibility. Where a user is 'currently talking to DJALOG through CONIT 
he must accept the order stated previously: i.e., (1) inode> (2) set 
number, (3) fj.eld types, and (4) 'document selection. With the current 
translation table mechanism there is no way for CONIT to rearrange the 
order. The offline output function-^-in DIALOG is acconplished by a 
different command (PRINT) than for online output (TYPE); therefore, 
the trode argument must be considered in conjunction with the show 
command name to determine the output translation. Also note that for 
DIALOG the user^cannot how specify in CONIT the docs ^rli argument with-^ 
out also specifying the| fields argument. 

2.4.6 Saving^' Output 

A rudimentary capability exists within the current experimental 
CONIT for saving the results of searches from different da.ta bases and 
systems in a common file created and stored by the interface and from 
which the user can display sections for subsequent' online viewing. 
First a file is set with the 'name-file' (abbreviation :nf) cbmmand 
v/hich has the syntax 

nf filename 
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If filename names existing file, that file is opened for viewing or 
appe nding t^ , riio name does not yet exist a new (einpty) file with 

that name is created and designated for storage. 

The command 'file' signals CONIT to append ^he response to the 
next succeeding command to end of the current 'saved file. Thus the 
sequence 'file* followed by 'show.:.' will cause the output of some 
search set to be stored in the saved file. The command 'view filename' 
causes the number of lines of text in filename to be reported to the 
user. Finajiiy, the command 'lines 2r}C causes lines j thru k of the cur- 
rent .saved file to be displayed online. 

2.4.7 News and Status of Retrieval Syste ms 

Certain kinds of news and status information have been provided 
as parts of previously mentioned functions: e.g., broadcast news on 
login; database status on 'show data' commands; and timing information 
on login, Ipgout, and database selection. The CONIT command 'shpw news' 
IS the common means by which a user can request display of the starrdard 
news message from the currently active system. This command gets trans- 
lated to 'Tnews' for DIALOG; '"fJEWS ' for SDC, and '""NEWS' for NLtVMEDLINE. 
There is no translation to SUNY/MEDLINE , as such, but rather the evoca- 
tion of a message (see explanation of 'sunynews') which explain^ that 
MEDLINE news can only be obtained from the NLM/MEDLINE sy tem. Note, 
again, differences amon<5 the several ORBIT systems. 

2.5. Systems Analyst Functions 

The CONIT functions we have described above have b^en those that 
make up the us,er_jLnter face , i.e., those communication components of the 
interaction directly used by, or seen by, an end user ^ i.e./ a user 
whose main purpose in using CONIT is to find needed information "from the 
data bases. We shall now describe those online interactive capabilities 
built into c6nit which assist a systems analyst to monitor, modify, and 
evaluate CONIT. Of course, some of these latter capabilities may be 
adapted to be useful to the end user as we shall indicate. These 
capabilities, together with those of the user interface and those , 
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and those corresponding capabilities available to a programmer of CONIT's 
host system (MULTICS) , make up what we might term the design interface. 

2.5.1 Translation Tables <v 



The command and response translation tables can be created, listed, 
and modified online. The command 'set table [out] tablename' (abbrevia- 
tion:st) causes a file with the name tablename [out] to be set up as the 
currently active table; if no such file exists, an (eirpty) one is created. 
If the optional argument ' o u t * is present, the table is taken as a 
response table and the fi.le name is taken to be one with the string , 
'out' appended to the end of tablename (i.e., tablenameo ut otherwise, 
a command table is assumed. Command translation tables might be use- 
ful for implementing a "rename" feature for users (see Section 4.3.3.5). 

To enter a rule in a currently active translation table one uses 
' the commands* 

replace [out] $ matchstring=replacementstring [ | ] 

•(abbreviation for replace : rep) , where matchstring is to be'set as the 
left-hand, or argument part of the rule (see explanation in Section 2.3) , 
and replacementstring is the right-hand, or function, part, of the rule. 
Again, the optional argument 'out' is used when, and only when, the 
response table is intended to be modified. The optional delimiter 
vertical rule (j) is added after replacementstring in case that argument 
ends in a space character which would otherwise get discarded in the 
regular CONIT command-parsing operation. Note that presence of spacing . 
characters m the argument and fui>ction strings ca n be extremely 
critical to the proper interpretation of a rule. 

To list out online the Current contents of a translation table, 
the c-mmand 'list table [out]' is used (abbreviation for list_table :1 t) . 
In the listings of translation tables in appendix C the argument is the 

string* between €he left-hand margin and the equals (=) sign;^ the 

/ 

function is t|ie striag between the equals sign and the asterisk (*1jj 

\ ^.^^.2 Dialog Modes and Language ^ 
Besides the argument pair TERSE and VERBOSE (see Section 2.1), 
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the SPEAK command can take other arguments to modify the form of the 
dialog. The argument 'monitor^- can be^ used to cause CONIT to display 
the full dialog taking place among' COnIT and the' retrieval systems air 
well as the cuStomary CON^T/user dialog whi^h includes only a translated, 
version of, what the retrieval system communications were. Appendix B 
shows examples of MONITOR mode output, w^hich can be very useful for 
debugging or demonstration purposes. In addition there is a mode evoked 
by' the argument 'no_screen' (abbreviation :nsc) whiJh causes CONIT to 
pass through certain formatting characters that aije ordinarily "screened 
out" from retrieval system responses. The argumerrtr-'k^ser ' is used to get 
back from MONITOR to regular (USER) mode and the argument 'screen' is 
used to return to regular mode from NO-SCREEN mode. 

The SPEAK command can also be used to go into a "transparent** 
mode of operation in which the command o;f the user are passed along to- 
the currently connected system without translation and, likewise, the 
output from the system is passed back to the user without modification. 
The user is thus speaking th^ language of the connected (host) system. 
To enter this mode a user types the command 'speak conit'. Note that 
once in HOST mode the user can issue no instruction to -be interpreted 
by the interface as such excep't 'speak conit*."* All of these four SPEAK 
mode pairs are independent so there are 2 =16 possible mod^ combina- 
tions. I 

* 2.5.3 CONIT Status Reporting ^ 

CONIT can report the status of the currervt language, current 
modes, current host, patch connecjf^Ton^, and TIP port use. The^ in-- 
formation is reported upon user issuance of the LIST STATUS .(abbreviation: 
Is) command which can take one of six arguments specifying the kind Qf 
information as listed below: ' . . 

(1) 'system' (sy^) — the currently selected system and the 
other active system (if any). 

(2) 'language' Clang') — the current language ^(i.e., CONIT 
•* only, for now, since user can't get this infonrtation in 

host irode)y^ ' 
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(3) 'mode' - the currently "selected modes such as VERBOSE , 
or TER5E; SCREEN or NO^SCREEnV and MONITOR or USER. 

(4) 'tip'- ---the TIPS -and ports . currently beijig usedk^^ ^ ^ ^ - . 

(5) 'patch' — the name o-f system currently connected to 

the patch ^ „ 

\ (6) 'all* — information on all of the above. 

. One will note in the translation tables the rule 'Is all=ls all'. 
This is a current device making use of the longest-match principle for 
preventing 'all* froip being translated as for the argument to the SHOW 
command. 

Mode selection and 'staUis/^view as features for and users are 
discussed below in- Section and 4.3.7^ * ' ' * 

2.5.4 System and^^IP Port Attaching and Detaching 

The CONIT analyst can establish a connection to an ARPANET TIP port 
independently of whether or not there is, or will be, a connection' made 
to. a retrieval system over that port. The PICK commahd is used as 

follows: 



pick ' tipname portaqgiber 

where tipname is the- name of .some TIP (e.g.^, NBS , MIT) and portnumber 
is the number of the port to be connected on that tip. ThU^, 'pick 
NBS 50' will cause CONIT to attach the user to one of the 5 ports on 
the NBS TIP that are regularly attached to the NLM/MEDLINE system, 
without forcing a login to P4EDLINE as such. 

CONIT also provides the facility for detaching an ARPANET TIP 
port connection by the command 'detach' (abbreviation :det) . If the 
ai;gument to DETACH is a retrieval system name, CONIT will detach (close) 
the connections to the TIP port through which the connection to that 
system had been made. Alternately,, any TIP port connection can be de- 
tached by the commnand "detach tipname portnumber ' 

\' - ' ' ' ' 

2.5.5 Connecting and Disconnecting CONIT 

CONIT 4nay be evoked by issuing the command 'conit' at the MULTICS 
command level. To get to the MULTICS command level requires logging in 
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to MULTICS. This, in turn, requires (1) calling up the telephone number 
appropriate to one's terminal type, (2) setting up the terminal^o- 
telephone connection in data mode through ♦a modem, and (3) issij^^ the 
'login- name *'^ 'command followed by a password consistent with the personal 
name given in .the name argument of -the LOGIN command. MUI/TlCs is fussy 
about upper-case/lower-case distinctions and the user must be careful, 
for example, to capitalize just the first letter X)f the name. Of course, 
\he name used in the login must either be the official name for the 
CONIT directory (Conit) or some name which has access rights to that 
directory. 

Users may connect to MULTICS through the ARPA and Telenet net- 
words. That involves dialing a TIP (terminal interface processor - 
satellite minicomputer) , establishing the terminal connection (including 
typing a character strinr; identifying the terminal type,, issuing a call 
to the MIT MULTICS computer ('o 44' — i.e., bpen connection to computer 
44 [MULTICS] for ARPANET, or 'c 617 mf or 'c 617 ms ' — i.e., connect 
in the 617 telephone area to a MULTICS fast* (1200 BAUD) port .or to a 
MULTICS slow (300 BAUD) port, and. then performing the ^MULTICS login 
procedure as- above. 

Users quit the CONIT program by giving the CONIT command 'exit* 
(abbreviation : ex) after which control is returned to the MULTICS command 
level. Any MULTICS command may then be given includinrg 'logout' which, 
disconnects the user from MULTICS. Disconnecting from ARPANET or Telenet 
is -^^complished by breaking the telephone .connection. . 

If the user has logged in to the CONIT directory in MULTICS he ' ^ 
is captured by a "start-up e^cecutive corpmand" program which automatically 
calls CONIT for iiim. Whenever the user leaves CONIT — either voluntarily 
by the EXIT command or^irrvoluntarily from a system failure, the executive 
program automatically logs the .user out of MULTICS . Access protocols 
that would be easier^^o use in network situations are discussed in Appendix 
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3. USER/SYSTEM lOTERACTION: GENERAL PRINCIPLES 

3.1 Importance of the User/Syste^ Interface ' 

Online interactive conpute A s:?s terns are relatively new, having 
been in existence only about fifteen years. There is just now developing 
a body of literature ^-^"^^ ' ^^"^"^ wh\ch describes and evaluates features 
and facilities of the computer system yhich the user .directly perceives 
as ne interacts with computer. These system features and facilities 
include such system components as: (1) tlrt^ command language; (2) the 
response dialog from the system; (3) "help'' or other instructional 
facilities; and (4) user terminals. These system components are often 
knov^'n collectively as the user/system interface (or, simply, user inter^ 
face). In our terms, the user interf^ace is ju^t one aspect — ^the "front 
end" — of the mt^f ace/virtual system which connects the user to re- 
trieval systems through an interface system. 

Despite the recent analytic -work in the area of the user inter- 
face , there is, as yet, no agreed upon set of principles by which to 
measure or evaluate this critical component of j,nte^actTv?"Ty3l:^m. 
(The discussion in Section 1.3 emphasizes this -point.) Needless to ^ay , 
there arc no existing, wide ly-knowg^^ope rational online systems that 
are generally accepted as having anything approximating ideal user inter- 
faces. In such a situation it is inportant that we atten^ to describe 
the general principles which motivate us in this area and which r clearly , 
can strongly influence the nature of any analysis of translating Cpn^uter 
interfaces for interactive systejp^^ Such a description follows in i\is 



section. 
3.2 Classes of Users 



\ 



At least some of the ^ontroversy s^rounding the user interface ^ 
issue is, undoubtedly, caused by a failure to distinguish the several 
classes of users who may be engaging the systems. Earlier, in Section^ 
1.3, v;e discussed some of the different^ kinds of users. Cfne distinction 
that we made for retrieval systems was between an end user andean inter- 
mediary. The end user li/i a person who needs the information that is 
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derived from the. data bases directly for his own work. The intermediary, 
who may be an information specialist acting as a delegated searcher, 
finds, information for the sole purpose of passing it along to an end 
user. 

Besides their classification by function, users need to be dis- 
tinguished by their experience. Relevant experience comes in three 
categories. First there is the category of conputer experience, expecially 
in regard to interactive systems and particularly with retrieval systems.^ 
Second is experience with the function to be served and the intellectual 
tools available to serve that function — in our case the bibliographic 
retrieval function with the tools of bibliographic reference using 
knowledge of data bases, indexing and classif i,cation structure, etc. 
Third IS experience with the subject matter of the data to be retrieved. - 

Thus, typically, the intermediary information specialist is / 
experienced with the retrieval system and bibliographic search function, 
whereas the end user is experienced with the subject matter. Both classes 
■^of u^ers are, in general, much less expert in the coirplementary areas. 
Of. course, individual users possess varying degrees of experience in 
each of the three areas. The iitiportant point is that, in each of the 
three are^, the inexperienced user needs more hel'p from the system than 
the expert user. 

To date online systems, ,in general, have tended' to be far from 
satisfactory for the inexperienced user; retrieval systems in particular 
have tended to work well only for an intermediary information specialist. 
One of our main goals is to consider what are the necessary prerequisites 
for system design by which the inexperienced user — especially an end 
user — can make effective use of online systems. Of course, a good 
system should train an inexperienced user how to become an expert user 
in time. Therefore, the good system should also allow for modes of . ^ 
operation that are efficient for the expert user and a mechanism fpr 
conveniently switching from beginner to expert mode at the user's dis- 
cretion. In what^follows belov we try to outline some other general 
prin"ciples that suppprt this basic one we have just described. 
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3.3 Instruction; Coirouter-Assisted and Oth^r 

Because a relatively large number of potential users of interactive 
information systems are inexperienced in one or more of the areas de- 
scribed' above , it is very inpqrtant to provide sufficient instruction 
to these users so that they can successfully take advantage of system 
capabilities . 

There are several media for instructing users: (1) a personal 
medium m which human instructors te^ch system use; (2) a standard audio- 
visual medium including printed guides and manuals, slide and audio in- 
struction , etc. ; and (3) computer-assisted instruction (CAI) in which 

the computer itself is the basic medium by which assistance' is given. to 

2 3 26 

the user. It has been suggested ' that conputer-assisted instruction 
IS likely to prove by far the most cost-effective means for teaching system 
use. Cf course, there can be combined media instruction as, when the 
corputer provides a real-time '*hot-line" to a human aide or when the 
conputer integrates and directs some audio-visual instruction. For ex- 
ample, an "online consultant" .facility is available on MULTICS by which 
users can ask questions on their*= terminals and rece^ive answers about the 
MULTICS system .^^ ' ' - 

in any case, our concern in our current work is primarily with what 
^the interactive system itself can do to assist in the training and in 
otherv/ise aiding users in the use of the system. We shall outline' in the. ^ 
rest of this section some princi^pies pertaining to computer instruction. 

3.4 C omputer Techniques That Aid Learning * 

Two prime requisites for interactive systems are clarity and 
simplicity. The dialog from the system sjiould be clear and easy to 
understand. Clarity requires succint, unambiguous. expression of con- 
tent for the individual messages, easily landerstandable format in which 
the messages are presented, and an ordering of the messages in a suitable 
sequence and structure so that user is led easily in a step-by-Step 
fashion from his current state of knowledge to the^desired conclusions. 
Information should- be provided to the user at .the time needed — or, at 
least, with maximum' probability that this should occur — so as to * ' . 
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optimize its effectiveness.^ \^ile the principle of clarity seems obvious, 
it may not be 'easy to adhere to. Opacity and ambiguity abound in inter- 
active systems^ as they currently exist. , 

Sirplitity is another cardinal principle that may appear obvious 
but is not necessarily easy to irtrolement. Any complexity presented to 
the user will tend to confuse and, thus, inhibit successful use of the ^ 
system. As system features multiply the^e is a tendency for the user/ 
system interface to become more and more c^qplex. Three avenues are 
available to the^ystem designer to avoid unnecessary' complexity : (1) 
design ^tjie^hole system with careful foresight so that ita- elements and 
interrelations naturally form a coherent who^e (including the design of 
instructional modes within the system) ; (2) apply the principle of 
clarity in instruction to^s±7???li fy the, explahation of the system' (in- 
cluding t):3 use of illustrative examples when appropriate) ; and (3) make 
the system modular with a simple basic Sfj^e as explained below. 

A simple basic core means that the basic functions can be performed 
by using only a few simple commands. Only a few options are presente<3 
to the user; most options generally' available from .the system are hidden 
and take on default conditions. The user can ext^^nd from ^the core to 
other operations as he leams, at his own pace, what the other opinions 
are and how to use them. ' 

Rapid response _ from the system is one requirement for online systems 
to' be truly interactive. Generally speaking, delays in system response 
to a user request of more than 10 seconds cause contusion, frustration, 
interrupted train of thought, and other bad effects on' the user. It is 
desirable that response times be less than 10 seconds and as short as 
possil^le — although shortening times ,to less than one of two seconds I 
may not be very useful. If the' full request cannot'^e satisfied in a 
short time, it is 'of ten possible to start a response giving a' partial 
answer within an acceptable time. 

The user should be kept aware of system status , espec^ially where 
rapid response is not possible.. Just as indicators of the floor position 
and direction of travel of an elevator can make waiting for the elevator 
more bearcible to the user (or can*help the user decide not to wait any 



logger) , so too can the knowledge of system status relieve frustration 
and aid in control decisions for users of interactive systems. Of course, 
this principle must be balanced against the one of sinplicity so that 
excessive and confusing information is not given. 

To help the user make sure his wants are being correctly under- 
stood ^he system should feed back its interpretation of a user reque3t 
as a preliminary response to that request. Thus, the system may in- 
dictate an obvious error in syntax or the user may detect an error un- 
detected hy the systems or a request otherwise undesired. Such feedback 
also acts as reinforcement to the user of correct system I^guage and 
actions , 

User control and flexibility in deciding what to do, and when, 
makes for optimum effectiveness of user/systen\^ interaction . The actions 
to be performed may be retrieval operations or informational requests. 
One kind of c/ontrol that is extremely inportant for interactive systems 
is the ability for the user to internet the system, especially where 

(1) the system response is unacceptably sluggish (overlong response 
time) ; (2) the system response is overly lengthly (too much output) ; or 

(3) the user simply wants to> change the direction or nature of the 
interaction without having to walt--for the current operation* to run to 
completion . 

Flexibility implies an ability of the user, and the system, to 
-^-dk^amo^ several modes of interaction according to the current class 
and state of the user and other context. A listing is given below of 
some the more important modes that are possible. The modes are 
listed in mutually exclusive and opposing pairs and each pair may re- 
present the choice, along one or more of t\ie instructional dimensions 
di^cussed above, of what de.gree of help^^p^r an inexperienced user, or 
user control for an experienced user, is desired. 

(I) VERBOSE/^ERSE , IJhes^' tnodes relate . to, the length and 
S. and compfrehensiveness of syste^n dialog. Thejre could 

conceivably be ^tnore than two modes along this spectrum, 
'but it may be more important to switch among these 
modes for individual* messag'^s ' thcin to establish a 
whole third' level. 
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(2) INSTRUCTIONAL/SERVICS . These modes ' relate to how much ^ 
en^hasis in- the system dialog is put on instruction 
versus the provision of retrieval service as* such. At 

one extreme there could be a coir^letely tutorial mode 
whose sole purpose was to instruct ♦ In general, there 
may also be a more or less pron^ting and other instruct- 
ion given in and around service operations. 

(3) INTERPRETED/STRICT . In a STRICT node the system does 
exactly what the user requests. In the INTERPRETED 
mode the system goes beyond exactly what the user re- 
quested. For exaitple , in a search in STRICT mode only 
the exact term as given by the us^r is searched, where- 
as in INTERPRETED mode an attempt is made to extend the 

V search to terms related morphologically (e.g., as by 

stems) or semantically (e.g., as by thesaurus relations 
in a Master Index and Thesaurus). As a second e'xairple, 
in the translating interface situation a request that 
could not be translated exactly is, in STRICT mode, in- 
dicated as such to the user, whereas in INTERPRETED 
mode an attempt is made to find an approximate trans- 
lation. ' ^ ' ' 

(4) AUT OM AT I C/ A S S I S TE D . In AUTOMATIC mode the system dimply 
goes ahead and automatically does what it thinks best 

for the user, whereas in ASSISTED mode the user is allowed, 
and encouraged, to assist the system in making decisions. 
For ihe examples mentioned in (3) immediately above in 
the AUTOMATIC mode the system, itself decides how to ex- 
tend the search, or make the translation whereas jln the 
ASSISTED mode the system simply lays out for the user 
the options and lets him choose. 

(5) H I DDEN/EXPOS ITORY . How much sTiould the system tell the 
.user about what is going on? In the EXPOSITORY mode 
the system. exposes a great many details (e.g., all the 
steps of a login process in connecting to a remote host ♦ 
through the translating interface) . In HIDDEN mode the 

, , system assumes that the user shouldn*t (needn't) be 

concerned with the details (e.g. , simply report the suc- 
' cess or failure of the aforementioned login process) . 

" (6) VIRTUAL/TRANSPARENT . For the translating-interface/ 
virtual-system approach a question is how thoroughly 
the virtual mode can be achieved as contrasted with ^ ' 
making the interface be simply a transparent connector 
to host systems that the user must deal with in their 
own languages. 
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(7) I NEXPSiHENCED/EXPERT , For the inexikrienced user all 
of the first-mentioned modes' in the 6 above mode pairs 
are, ideally, chosen as a default mode. For the expert 
user either the conplementary modes aVe chosen or the^ ^ 
user is given the option Of what mode^ he wants. 

Of course, as indicated in the discussion\ of VERBOSE and -TERSE 
modes, there may be many intermediate situations Wtween the opposing 
mbdes in each npde pair. In the sections that .follow we relate in 
greater detail the application of these principles^ of user/system in^ 
teraction to the case of a translating interface tc^ ritrieval systems. 
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4. A COMMON LANGUAGE FOR RETRIEVAL 

As discussed in Section 1.4/ we are experimenting with the net- 
working of retrieval systems in which a con^uter interface presents to 
the user a single virtual system based on a set of common features. 
Features that need to be put into-»a common form include the user cor?- 
mand languages, the system response languages, the indexing languages, 
and the bibliographic data structures. In this section we shall dis- 
cuss what specifications are appropriate to a common command language 
and, to a less extent, to a common response language, indexing language, 
and data structures. 

Such common languages and structures can serve as a basis for 
a protocol by which distributed components of an information retrieval 
network may communicate with each other in a standard way. The net- 
v^orking aspect of the common language/protocol will be discussed more 
fully in Section 5. In this section we shall discuss the common lan- 
guage itself beginning with a critique of English as a possible basis 
for the common language. 

4.1 English as a Common Language 

>^ 4.1.1 Advantages and Disadvantages of English 

It might be thought, at first blush, that natural language 
- i.e., ^English — would be a good common language for interactive 
computer systems.' English is widely used; i ^is the common language 
in this country '^nd in many other areas around the world. In contrast 
to the requirement to teach an artificial command language before it 
is used, English speakers vould not have to ±>e tau'ght English before 
using it as a language for conversing with tfte computer. English , 



is, naturally adapted to new conditions and uses.- Finally, new 

27-29 * 
developments in the fields of computational linguistics 'and 

artificial intelligence have brought economic computer .techniques 
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for handling natural language communications closer to achieverent. 

These consents about English are correct, as far as they go^ 
but they do not present the full picture. Of course, on an inter- 
national basis, there are many more potential users of interactive 
systems who do not speak English than who do. Thus, the correct argu- 
ment is that natural language has the-de^ired features of ease of use. 
English and' the other natural languages do not, then, present a single 
universal language and different — though perhaps similar — computer 
routines must be enroloyed to handle them as command languages. Also, 
while there are, undoubtedly important developments taking place in 
computer understanding of natural language , ' many of" these are still 
in an experimental stage, and we do not yet have adequate cost- 
effectiveness data to predict accurately . their success in our applica- 
tion. 

Furthermore, the most important po^nt to recognize, however, in 
considering English as a common command language is that gene r a 1^ kn owl - 
edge of the natural language does not, of itself, explain for a user 
what a computer system is capable of doing and what it is not. There 
is a vast disparity between the infinite variety of functions and 
requests that can be expressed in th'fe natural language and still rela- 
tively very few and simple 'functions that interactive , systems can^ 
perform. 

One of the main problems for at least: some users in making 
effective use of such systems is their lack of appreciation of the 
limited nature of system capabilities. ' The "super-brain" myth that 
vieKS cpmputers as all-knowing and all-powerful is one that con1:inues 
to confuse inexperienced users. To a user, then, to "state your 

request to the computer in (ordinary) Englj!ab" ntiay be misleading in 
two. ways : (1) it may foster the "super- brain" myth — the user may- 
»infer that the computer understands (any) English as well as (or better 
than) a human — and (2) it may postpone the necessary learning dialog' 
between user and system in 'that *1:he user feels %the computed will always 
"do its best" for 'him without any special knowledge or guidance of the* 
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system required by the user. (Note that this kind of misleading is, 
in fact, worse when the coir^uter cleverly — or perhaps, luckily - 
responds with what the user perceives as an intelligent response to 
his request.) 

One could ^ant the difficulties of using English as a command 

language and still promote its use for the ijser as part of a learning 

dialog . This position has some merit. Thus, for exainple , a user 

request, whether natural language or not, can be analyzed fairly sirqply 

for keywords so as to select an instructional message that is probably 

30 

relevant to the situation. (See Shapiro , for example). However, 
the use of English in an extended way to explicitly request detailed 
instructional information faces the same problems as for its use as 
a command language for retrieval functions. 

The problems mentioned above, and the even more serious problems 
^to be described below, can be alleviated by taking advantage of the 
interactive nature of the dialog: system and user can quickly converge on 
the proper understandings through a ques tion/prompt-and-answer exchange. 
However^ before we get into attenptec? problem resolution we should have 
a good appreciation of the detailed nature of the problems to be over- 
cone so that we can better assure ourselves that the proposed solutions 
fully address the proper issues* It is in this spirit that , we describe 
below some of the general problems of the use of natural language for 
command languages, and in particular in the information retrieval applica- 
tion , prior to our discf\jss:^n of -problem resolution which follows that 
description. 



4.1.2 The Ambiguity Problem 

The main problem with natural language is its ambiguity; that 
is, a statement can have many meanings. Usually speakers can resolve 
tliese amb'iguitie^ sufficiently well so as po get along with each other 
at a rpu^h ^^el- of understanding. Thi^ requires considerable mental 
capacity in terms of native intelligence, a large body of experience — 
especially experience shared among the commiiinicants — and the ex- 
tensive processing of ' linguistic c^ata^in contejj*^ When precise 
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conununi cation — of the kind we need for effective coirputel: system 
operation — is desired, however, a much greater requirement is placed 
on the communicants: they must either spend a considerable effort in 

conversational dialog so as to overcome the ambiguities for each case 

* 

or they must have a mutually: agreed upon precise language for co mmuni- 
catio;^' on particular topics under discussion. Therefore, we are 
'fa^d with either an extra conversational burden or with the need to 
levelop a more , precise language like the specific, formal language that ' 
the natural language was supposed to enable us to avoid. However, 
counterbalancing these ob'&ervations is the point that for a particular^ 
application we can build into the conputer routines that interpret user 
statements taking advantage of a knowledge of the limited context inplied 
by that application so that a fuller interpretion of \aser meaning is 
more readily determined. 

Therefore, in order to evaluate these questions further and to 
.make the above discussion more Qoncrete , let us take particular examples 
from the retrieval application. Consider, for exairple, the question 
of naming and operating on sets of retrieved docunents. Suppose that 
a user has performed searclies using these three search stiatements: 
(1) "steel metallurgy"; (2) "steel castings"; and (3) "fractures in 
turbine bledes." What, now, does a user say if he wants to find all 
documents that are in both the second retrieved set and the third re- 
trieved set (i.e., the Boolean intersection of sets 2 and 3)? 

First, one rhust realize that the user, based solely on his 
knowledge of ordinary EJnglish, does not necessarily know, nor will he ^ 
necessarily use, any particul^r-well--de fined nvethod of referring to ' 
a set of documents. There are, of course, many possible methods, several 
of which are actually used, as we have seen in Section 2.4.4. (For 
example, the n^^ set can be referred to as "^et n" , "sn", or just "n".)^ 
Even more fundamentally, and making matters worse, the user does not 
necessarily know the concept of 'intersection or that retrieved sets 
are saved or that they may be operated on in other ways. Such a. user 



52 

O -44- 

ERIC 



4.1.2 



might use any of these referral methods; or worse, some combination of 
them; or much worse, an ambiguous circumlocation in ordinary English 
phraseology. For exanple, he might say: 



(1) "Now everything on steel castings and fractures in 
turbine blades." 

(2) "Get a combination of castings and fractures searches" 

(3) "Can you show me citations on both the last two 
searches?" \. 

If the first statement were given merely to perform the inter- 
section it would represent a v^aste of user effort as contrasted with 
making a more con(^ise statement using a specific "set" notation. Note 
that a statement like (1) could easily be interpreted to mean t^at the 
retrieval systems should perform a fourth seairch containipg all the 
elements as given. Such an interpretation would be wasteful of computer 
and real time con^ared to 'combining existing sets; it could also result ■ 
in a set different frbm. the intended one deoending on how the search 
match algorithm worked. 

We may note that various ways of using the words "and" and^ 




some of which are shown in the 3 example statements above, are gener- 
al ^ ' ^ 
ally ambiguous in English • Thqs "and" can be variously interpreted 

in the Boolean union (OR) sense ("We have a set of four eyes here: your 

blue eyes and my Brown eyes") as well as in the intersection (AND) 

sense ("Between the two otyus the set of persons who are alive and have ^ 

blue eyes contains just one member"). 

■J ^ 

As an exanple in the searching application, consid^sr the follow- 
ing four (perfectly reasonable) interpretations of Statement (1) 'taken 
as a search request: 

1 - 

(a) (steel', castings) AND (fractures in turbine-tblades) 

(b) (steel castings) OR (fractures in turbine blades) 

(c) steel" (castings AND fractures) in turbine ^blades 
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(d) steel (castings OR fractures) in turbine blades. 

Sometimes semantic analysis and context clues can be used to help resolve 
ambiguities like these. However, automatic analyses may be conplicated 
and costly, and often, in any cas.e, the ambiguities can be resolvable 
•only through questioning the user himself for his intent. We note here, 
in particular, that language expressions for search topics are not limit- 
^ able in scope and context; they are, in this respect, unlike the commands 
themselves which are limited to the relatively few functions allowed by 
the system. This potential .wide range of applicability of search topics 
is especially true"" in the situation we are dealing with: namely, a 
multitude data bases covering many disciplines and document types, 
including those indexed under free-vocabulary as well as controlled- 
% vocabulary (thesaurus) techniques. ' ' 

Statement (2) could be reasonably interpreted as meaning either 
the intersection of the two given sets, as intended, or as a new 'search 
on just the two terms "castings" and "fractures". Alsb, it might t^e ' 
a fairly sophisticated algorithm to te]^ with any degree of assurance 
whether a word like "combination" in Statement' (2) has a functional 
meanirg or is intended as a term to be searchVd. 

Beyond the naming and referring toVetifieval sets, there are 
ot;her problems brought, up by the three example English statejients. One 
v^"' ^robj^m is whether a sea^rch function or an output function is bexnq * 
requested. The natural language is ambiguous on this score.. Of ^urse , 
here again, syntactic and semantic clues may be used ^o help resolve 
. the ambiguities. We may note, however, that even after it is determined * 
that a se^arch function is indicated, for exampli^, other questions 
^then arise: what is desired in the ^way of- a* matching algorithm, index* ' 
elements to be searched. Boolean combinations, and dat^a base "searched? 

Another problem that can be as thorny as the set-naming^ problem 
is (the naming and specification of bibliographic data elements, Take 
just the term "citation", for* example. It can mean (1) thle, references 
listed in the biliography at .the end of a paper, or (2) ti^ papers which' 
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have references (in the first sense) to a given paper, or (3) the 
set of bibliographic elements by which one can '•cite" a paper including 
the title, the authors, and, variously, feuch other elements as^ journal 
location, accession 'number , corporate authpr, editor, or other in- 
formation to identify and access^ the document. How to refer to these 
.various elements, either individually or in groups, is no simple matter, 
as this one exaitple illustrates especially in the absence of a 'standard 
bibliographic data structure ^and nomenclature. 

Finally, we m^y note that the- third' statement witft' it^feer- 
roga^ve form could be taken simply as a request for in format i(«fcout 
how Bp system works or an implied request to perform the questioned 
operation. ' 

^ 4.1,3 Elements of English that are Desirable and Practical 

The examples given above are clearly only a few sartples chosen 
to illustrate the point; they could be easily extended to elaborate on 
the problems of the use of unrestricted and undirected natural language. 

Of course, besides those automatic analysis techniques alluded to above, 

(J 

ansv/ers to these problems may aldo be found, in part; at least, in those 
modes of operation employing directed, interactive instruction to the 
user on what is possible, and how to express it so that he may clearly 
and unambiguously specify the functions to be 'performed. One good way 
to instruct in the intricacies involved is to express them in a pre- 
. cise, unambiguous language, that is, at the same time, as sirtple as / 
possible. Thus, because of considerations of effectivene^ as well as 
cost, we are led in the direction of extensive instruction and/or 
a restricted subset of English that would avoid the ambiguities* in 
expressing command functions. 

The question then becomes one^of determining which natural 
language elements can, and should, be'iQ^luded in a retrieval language 
for human use in the current state of evolution of computational 
linguistics.- We have not fully^^^^solved^ this question but we believe 
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such eleitvents should at least include: 

(1) , English words as conunand- language vocabulary 

terms;' * 

(2) "English-like" constructions for the commands — 
i.e., having the "flavor" of, but not full variety 

of , English; ^ ' * ' 

(3) English response to users (at least in VERBOSE and 
INSTRUCTIONAL modes) ; 

(4) a natural -language approach to a common indexing 
and search vocabulary;, and 

(5) at least a minimal capability for transforming 
a natural language request into a suitable re- 
quest for instruction on some system feature. 

The above basic elenerts have already been demonstrated as being cost 
effective. Of course, how far one can or should go in releasing the 
restrictions on the formal command language and extending the variety 
of English ponstruction and vocabulary that may be used is an important 
issue yet to be resolved. What our own analysis suggests is that the 
ansvjer to this question involves consideration of such interrelated ^ 
issues as: " v 



(1) how much additional' ambiguity is engendered in 
so doing; 

(2) how much (if any) does the additional flexibiliy 
provide in terms of greater ease of learning • 
and use; 

(3) how effective and how costl? pire the tf^chniques 
for automatically resolving these ambiguities 
(the answer to this question is one lindergoing^ 
rapid change in an. area of dynamic research and 
development) ; and 

(4) how effective are the subsidiary interactive 
instructional techniques in handling the ambi- 
guities not automatically resolvable. 
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In any case, how these five b'asic natural-language elements may be 
integrated with a more precise, formal command language is included in 
the discussion that follows of what a retrieval language should look 
like. . . 

4.2 Desired Structure and Features of Interactive Languages 

Halving discussed the general principles of the user interface 
in Section 3 and some considerations on the use of ordinary English, 
or elements thereof, in the common retrieval language, we are now m 
a position to list those features that. w|>uld make for a good language 
between computer and user. The"se general features are, to a large 
extent, we feel, independent of the particular application; the specific 
application to retrieval will be considered below in Section 4.3. 

The command Icmguage for expressing requests of a computer system 
should be simple and ,clea3|^Sn keeping with both the needs of inexperi- 
enced users and the limited nature of^jjja^t the conputer can do. In 
the latter respect, it should be able to mirror the simple basic core 
and modular nature of the optimum user interface (Section 3.4) in that 
the command language subset requir^'^ for the basic core should be very 
simple wJLth complexity added only as needed to request the more -special- 
ized functions. 

Let us assume the basic input mechanism for. the user is a terminal 
with the ordinaiQ^ typewriter keyboard cdntaining at'Xeast the alpha- 
betic and numeric characteristics and some punctuation. This assumption 
is made both because such input devices are now generally available 
and because it is not ob,vious at this point that any more elaborate , " 

devices (e.g., graphical input, light pens, function Switches and 

32 

buttons) can actually simplify the situation for the user. 

A simple command structure that lends itself to the above * 
criteria is one having a command name followed by one or more argu- 
ments followed by a command terminator: 

command-name argumep^t-1^ argument- 2 * . . terminator 
'-49- 



The argunient^are separated from each other and from the command name 
by siirple punctuation — e.g., one or more spaces. (The rationale for . 
specific character choices will be given below in Section 4.3.). The 
number of arguments is variable; in "the siirplest case there vould be 
no arguments at all. The command terminator, which in the simple case 
•acts also as an end~of-message indication, is a single special (reserved) 
character -r e.g., carriage return — which may follow' the last argument, 
or command n^me , without any (other) delimiters. 

Conmarid nair.es and arguments are primarily comiron JEnglish w6rds, 
iricl':ding nurhers expressed as numerals. Common functions should not 
require the use of shift keys. The shift op^ation tends to be error 
I rone and c.onfusing f6r many users. Also, therefore, upper and lower 
case alphabetics should be generally equivalent. This command language 
terminology should be. kept as unambiouous as possible. Thus, the same 
word should not be used with d:^fferent meanings. ^ 

This last requirement can start to raise complications in special 
cases. For example, wh^re free-vocabulary English is to be used in an 
argument, as in tht; search topic for ,the FIND command, there needs to 
be a m.echanism for distinguishing a word in the controlled language 
t^^rminoloqy from that same word used in a free vocabulary sense — a. g. , 
author as an argument of the FIND commnand meaning either search in the 
author index or search in (any) index for the word "author"* One 
mechani3nr following the English convention!, would be to enclose the 
v;ord in quotes when used in the -free-vocabulary sense - e.g., 'find 
title "author"* to request a search for the word "author" in the title 
index. 

Further extensions to the language are needed to help users make 
the nest effective use of the system. Pre-defined abbreviations for 
conmai, 1 terminology should be allowed.' Any prefix of a pre-defined 
vocabulary term should be allowed as an abbreviation as long as it is 
not airhiauous with another term or prefix. (If such an ambiguous pre-, 
fix were used the system should query the user on his intention.) 
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Beyond simple abbreviation the user should be allowed' to use 

his own terminology by establishing synomyins for system language terms. 

Again, avoidance of anbiguity. is the chief concern. One can also con- 
* 

ceive of rvore coirplicated translations than just word-for-word synomyn 

replacepent. (See Section 4.3*3*5). In'effect, the user should be able 

to construct his own dialect; the moot advanced user would have a dialect 

with macro-like substitutions allowed. ^ , 

The user sriould be able to string seve'ral conjmands together in 

one statement. This can be easily stated in the language if there is 

a corrand terminator distinct frofn the end-of-statement character. - It 

nay also be convenient to permit the use of speciial characters attached 

1 

to, ar connecting, arguments to indicate special functions like stemming 
and lir^kj^XK^ in search requests or editing (correx:tionl of user input. 

Or.e.^Tvajor addition to the basic structure described above, which 
is needed to provide a convenient mechanism for stating relationships 
among arguments, is the subdivision of the arguments. Thus, for example, 
to indicate which documents to putput in the SHOW command, the elements 

and "k" in the argument "docs j-k" aire really subarguments to the 
primary argument "docs". (One might also say that "docs" is a sub- 
function or subcommand o f the SHOW command) . The more Complete language 
structure then allows subarguments for arguments; sub-subargumfents , 
and even deeper levels, ai;e possible. It is desirable for simplicity 
to contain the logical depth of subarguments as much as possible. Also, 
, to avoid complicating terminator requirements for subargument strings , 
it is desirable to makfe the argument structure apparent through the 
constraint on terminology in command and argument context. 

Thus, the overall statement structure can be signified first 

where C. is the ith comman(3 and the semicolon is used as command termi- 
1 

nator. The command structure -is represented as follows 
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V 

where N is the command name, A^ is the ith argument, A^^ is the jth 
subargument to the ith argument, n is the number of arguments, m^^ is the 
number of subarguments to the kth arg^iiment, and only one level of sub- 
arguments is shovTi. (No sub-subarguments) . This structure is illustrated 
in Fig. 5. 

Generally ^^peaking, the interpetation of user requests should not 
vary with the reordering of arguments (or subargument^) . Users should 
not be burdened^with remembering some fixed order for elements, at least 
when they are essentiall" independent of one another — like, e.g., 
^he arguments to the output command. There are, of course, cases where 
order is important and* may .need to be preserved in the command language 
as where one was specifying a particul^V ordei* for terms to be matched 
in a search request. Ultimately , as' dialect-creating macros beeome 
sufficiently sophisticated, the expert user should be allowed to take 
advantage of ordering to shorten commands. ' . 

Users, also, sho.uld be generally free to give commands in any 
order they choose, 'as long as it rakes sense. Thus, for ex^ple,* a 
user sho^ild not be forced to scan an index display before making a search 
if he feels he knows what search terms he wants to use in the first 
place. There is a mode of operation of interactive computer systems 
m whicn the user is forced down a very particular path by, for 
example, having to "fill" in the blanks." Thus, for ej^anpje, the user 
may be asked what data base he wants to search and the only response 

can make at that time ife the designation of a data base\ We do not 
advocate this respond-to-prompt-only mode because, first, it is so 
(pont rained and, second, ev^n in the instructional^ situation for which 
It is often employed, - this mode postpones dem.onstrating the command/ 
argument type forpat wliich the user needs to' make effective, individual- 
ized use of a system. 
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•The system may, of course, ask a specific question such as^"Do 
you want to see more output?". However, the user should be free to make 
a commnd other than in direct response to the question — e.g., a new . 
search request. Also, the guest ion can probably be posed so a^ to'. 
proiTjpt a response in the command/argument format, thus instructing ,thfe ^ 
user in a more ^generally useful mode of communicating. -For example ; ,the 
output question^-aboA/e^could have been stated as an impe^rativet "To see 
more output .type *show more' (or 's m* or 'sm*)'." Another advantage 
of this, command/argument tyjpe instruction is that the user is being 
shown commands, that he may apply, without prompting in th'is and other 
situations. ' " * ' v , . ^ - 

4 . 3 Speaific Plans for a Retrieval Language/Protocol ' 

4.3.1 ^General Consideratiohs i' * 



Having disoussed^ the general structyir^ and spme features that 
T^ake tor a desirable interactive language, | we now consider how these 
^ general' id^as may b^ applied to .the^ speciflic application of retrieval. 
We shdll be extending, generalizing, and ttiodifying .^he language frame- 
work of the CONIT experifnental system described in Section 2 as welj. 

. . ' . . ' / . / * ' 

as trying to justify the choices made. The language described here 
' ' / . • 

will' not be cQirplete in terms of all possible retrieval functic5hs' oi: 

lancjuage spe.cificafcions. While what' we suggest here is incomplete and 

t toward normative specific' 



S rai'sing issues surrounding 
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tentative, we are, at least making a *sta: 
cations for retrieval . languages as well 

the langliage ques^tion. We owe a debt td' Martin whose extensive 
degctiptions 'of features of online retrieval system^ h eared the 
way for an attempt at'. prescriptions ^ 

- Some f uncCion$ needed in the i-etiri^val -language .may he very 
.specific to the retrieval- cipplication , /'others less so* It is worth- \ 
v/hile to cafeegori^e this sp^^cifically /irito three levels. Some functions, 

like ?earch and set combinatiqn, are quite particular to the fetriieval 

/ ^ ' 'A ' / ■ ' ' ' ^ ^ 

application. A second class of funct/ibns, like initial connection to , 



the system and mode selection, are equally vital to a 'wide range of 
applications- The third class of . functions , like editing (correction 
of user-statement typing errors), are, in the retrieval application, 
limited' subsets of the functions performed more generally in another 
application (online text , inputting and editing, in our example). , 

The reason for making this three-part classification is so that 
we can consider the interrelationships amo/ig the retrieval language 
specifications and specifications for other applications. .The goal 
of integration of or, at least, standarization and compatibility 
among different applications as discussed in Section l.l,^inpel^ 
us to consider these 'interrelationships . Thus, for the third class 
of functions^we would want the retrieval' language to be a subset of — 
or, at least compatible and consistent with' — *any generally accepted, 
standard language with a more encompassing expression of these functions 
In this case, hopefully, the subset will fall out simply from the t 
larger set. Conversely, we would hope th'at the retrieval-specific 
functions of the first class could b6 dimply adapted in other appli- 
cations; the simple-basic-cor^ principle should aid that goal. 
J " Finally,^ for the second class of functions, we should try to 
choose specifications that are suitable for other applications as, well 
as the retrieval one.. Since there are n,o generally accepted, standard 
application (tas"k -oriented) languag^es' ^ow, nor is there an accepted 
measure of consistency or* compatibility among languages, we must expect 
our current atteirpts to be only tentative and s^ubject to modification 
as developments' in this area progress > 

Another reason for tentativity • is our unc.erVainty for a system 
to be implemented in the near future of exactly what functions would 
be included or how sophisticated they would be. Of course, the further 
in tiie future one goes, the cloudier the picture.^ Therefore, any 
langXigage framework suggested at this point should be modular, flexible, 
and extensible- * " 
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We have previously distinguished the response language from the 
oormand language. Since the response language is largely in English ~ 
especially in the VERBOSE and INSTRUCTIVE modes ~ we ryeed not be so 
critical abont its form and structure so long as it satisfies the general 
principles of Section 3, Of course, .the^^terminology should be consistent 
^ with' and, indeed^ be didactic for, the command language. In the command 
language discussion we shall make some .comments on the cpntent of the 
response language as pertaining to the command function undero discussion . 

We should distinguish various levels of language. The command 
lanqi^age itself is what ^ user actually uses to issue commands.^ The 
exposition language is a metalanguage used to explain the nature of 
the command langliage, as to a user with the response language or to a 
meta-user analyst (e.g., a reader of this report). , An ^ internal language 
is a representation intejrnal to the system pf user commands, system 
responses, and other s.t'atus information*. There may be Several internal 
representations as^ the comi^ands and other messages are passed back .and- 
forth and each one requires, of course, a metalanguage of its own to 
describe it. The need for and nature of inter^nal languages will be 
discussed more fully in^Sec|*ion 5. 

,The corrtrr-and^aangua^e is conceived as being flexible and adaptable 
to user^ Variatiopl^in a waJ/ not .^xplicity i^dicate6 in the exposition > 
; of each coirjt^^nd itself. Thus, upper and lo^er case variations in al- 
" ^fhabetic characters and variable spacing before or after terms and 
delimiters as expressed by a user, are^^sidered equivalent to the 
singlecase, single-space standard fp/m. / The eicposition language may 
b^ different for 'user and analy^ . Fot example .* the .user mav have 
difficulty with metalinguistic /devices/ like quotes. When the system 
says "type ^show more'^' ttife, us;er may ^Onder yhether he must type the 
single quotes, especia^dy whc^e some^/^ys terns do actually ~ unfortunately 
{see Section 3) --jr^^ui re, quotes o^^oth^r t>unctuatioy( to distinguish 
one type of commanfi f/om another. jT^erefore, we sugiest de-emphasi^ing 
^ tho^o kinds of me^ai^nguisyic devi^ps foil the user, /as opposed to the 



4.3.1-4.3.2.1 



t 



analyst. Metalinguistic devices that are Better for the user would 
include those devices that would be less^"" likely to evoke a user attempt 
to mimic; for exairple, exanples to copied or modeled by the user could 
be indicated by a different typ^ font or color or a separate line with 
special indent^ation. 

The device ,we have chosen of using capital letters to refer to 
»a command name ^ a con^roraise that is not ideal because it suggests 
capitalizati^ which should be avoided by non-expert typists. Our 
attempt's^^^^ handling these problems may be seen by con^aring sections 
3 and^^ (intended for the reader analyst) with the dialog of 'Appendices 
A B (intended for the user) . 

^.3.2 Retrieval Language Structure 

i i 
4.3.2.1 Commands/Arguments/Delimiters | 

We take as a basis the "open" command/argument structure de- 
scribed in Section 4.2. The space character is jtaken as the ^delimiter 
between command names and. arguments' which are, at least for the simple 
basic core, common English words. This structure gives the simplicity • 
and mnemonic value associated with simple^, English-like phrases or, 
more exactly, iitperative (verb) clauses. 

^. Characters other than space (e.g., comma, period) are not nearly . 
so "natural" in this respect nor do they separate terms so "clearly" 
to the eye 'nor are they as widely used 'in existing interactive languages. 
Any oti^er punctuation or special characters (especially mixtures of 
different character types) and required .abbreviations represent un- 
welcome complexity and mnemonic burdens to a novice or irregular 
user. The one problem wijih space is that it is a non-printing character 
and you cainnot "see" it; where this matters ~ e.g., where the space 
has not (yet) been followed by a printing character — the difficulty 
is reduced if the input ^evice has a good type-position indication. 

(Some of these considerations, especially as related to initial system 

34 • ' 

access, hav^ been discussed by Neumann. ) 
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4.3.2.2. End-of Message Si^al 

Similarly, a carriage rfiftum provides a simple, easy-to-xanderstand 
end-of-message signal. The^SCII new-line character is acceptable also 
if the carriage return,.^ature is either included or added on (echoed) 
automatically. J^^a user statement should require more than one ^ine 
to conplej^e^he user can cancel the normal ^fect of carriage return 
by p^^eding it with a special character, like hyphen - which is 
^regularly used to indicate continuation from one line to the next in 
ordinary English. If a special device, like a function switch, is used 
to indicate end-of-message, it should cuase, a carriage return to make 
It compatible with the simple case. It is clearly much less satis- 
factory to have special statement continuation devices depending on 
the particular command to be continued. In a well-designed system 
statements of more than one line should be needed only very infrequently, 
for example, long search phrases should be selectable as tagged ele- 
ments from a dictionary display and the user should be able to break 
up strings of arguments and commands into shorter componei^ts. 

4.3.2.3 C ommend Terminator 

A qood command terminator is se.micolon Several systems 

already use it as such and it has a corresporjding 'meaning in oi^Jinary 
Enqlish. Even this small degree of punctuation for delimiting is - 
nr t desirable for inexperienced users. However, ^command stringing 
, , arid, hence, the command terminator; is not necessary; commands may be 
' \51sued on separate statements. • It may be possible to eliminate the 
n-.cd for command terminators if comjnand names are sufficiently dis- 
tinct. However, the use of free-vocabulary index terms and the possi- 
: ility of using arguments as separate commands (see below in Section 
^"^,3.5) complicates the parsing prx^b^^^^and may make it /inadvisable 
to try to avoid using tritj coii^^d tetminator in command strings. 



4.3.2.4 BracketiiHf \ 

7^ \ 



/ 



Delimiting ^-^racketi^ijg' argument strings may become necess^^ 
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in some complicated situations like the nesting of Boolean operations 
(see Section 4.3.5). The pare^ntheses could be reserved to handle 
those situations. 

4.3.3 Dialog Control * * 

4.3.3.1 Input Editing y 

The user needs to be able to ch^ge his ^Jjjp<ft statement before 
he coiTjTiits it to being sent via the end-of message signal. Two simple 
editing commands that cancel some or^^aTl^*^ t^e preceding characters 
in the current <mfinished statement should suffice for almost all 
situations. The deletercharacter comi^nand has the effect of deleting 
or canceling the last character entered by the usei^. The delete-line 
command cancels the whole line up to that point. Whether the canceled 
characters are actually removed and the type position reset, is a 
question of system sophistication. 

Natural characters to use for these edit functions are the 
ASCII delete (DEL) and cancel (CAN) ^characters . However, current in- 
put devices may requir'e shifting to get these characters. Also, 
current operating systems' may require other i^lementations of these 
commands. Until these conditions are ^lleviated it may be better to 
accept other solutions. Thus, 'in the current CONIT we simply use 
the number sign (#) and at sign, (@) , respectively, required by 
.MULTICS. . ^ , 

A simple extension^ of ^tbes^e edit commands is very useful. 
A string of n delete characters deletes the last n characters. An 
»analagous extension could be employed for the cancel line command in 
multi-line statements. Nqte that this is i>ne situation where tjie 
command terminator and other delimiting characters are not, and must 
not, be used in' a command string. ' * 

4.3.3.2 Interrupting 

As y/e have previously stated, the interrupt function is crucial 

ti 

/ 



\ 

to effective interactive dialog. Jts meaning, generally," is to abort 
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^'(safelY) tre execution of the last qiv^ user staterrent and return 
control to the user to nake a new request. If the user is still pre- 
.^paring his current statement, an interrupt would have the same effect 
as the cancel ll>ne(s) command but would also call . for a user prompt. 

In mo3t existing time-shai|p!ng systems thfe interrupt is ii^^pl^ 
merited using a special key — th^ BREAK key which transmits not 

a character as such but rather a change in line condition (to zero 

I 

h>t^te) for a specified period of time Tsay approximately 200 miljli- 
seconds). ' Such a signal cannot be transmitted through existing 'net- 
work connections without special hardware (although we have managed 



t^ fool at lieast one retrieval system host computer into thinki 



string of mill characters was break signal). Therefore , at ^s now 
beaoming accepted practice in network situations to reserve a character 
in the regular, character set to mean interrupt. For the common User 
command language such a convention should also be adopted and could 
be used in full-duplex operation. Note, also,, that the interrupt com- 
nand, unlike other commands, is used without waiflng for a user prompt* 



4.3.3.3 " User Prompt»s and Status 



. The current CONIT user\ prompts 



"USER::'/' in VERBOSE mode and 



" : in TERSE mode 



were mentioned in Section 2*3. Two colons are 



used because it is. felt that a gingle character .Wuld too easily be 

ambicmous with other feystem response, espec^a].!/^ in TERSE mode whe):^ 

/ + 
if^ might be lost due to transmi?ision or terrniri^l Stiming errors, for 

example. The colon is chosen over other punctuation (e.g., question 

f ^ /; 

mark (?) hyphen (-) , or greater than (>) ) because it most clearly 
seems to suggest the nption that something is/to follow. (E.g.; a 
^question mark is often taken to have the 3iqnificance ; "I couldn't 
understand your last statement - please/r^eat or rephrase".) It is,, 
fcrl, important that an- inexperience^^ us^ be given more than ju^t^ 
punctuation- as a prompt that it i^ hi^tum. The word "user" in con- 
junction vlith the colons nay have somcj advantages in suggesting whose 
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ttim it is over other terras that may be used, such as "ready" or "type. 

Vie have pointed out in Section 3 how user responsiveness and 
rapid feedback are essential to effective interaction. The user needs 
to know that the^ sysi:em and its components are working and that he cax^ 
axpect a response that is reasonably timeiy and worthwhile, Exanples * 
of kinds of status in format i^^j^ that could aid a user in' these respects 
are listed below: ^ 

, (1) The terminal is working; * * 

(•2) ^The communication channels are open; ^ ' 

(3) ^The controlling system (e.g., the interface) is 
operational ; # 

(4) Intemediate (e.g., network or operating) systems 

* or target (e.g., retrieval) systems are operational; 

(5) The^user nay now input a statement; 

(6) The user stateirtent has been 

(a) received, 

(b) interpreted successfully, 

(c) 'and this "is its interpretation ...; 

il) the user request is now being actively worked on", 
^ or is queued up, by the interface and/or some 
^ other systems; 

" . < ^ - . 

(8) For t.ie current user request it will take so 
much longer^ (real time) to begin (or' finish) 
" a response at the following estimated cost. 

To what*extent, in what manner, and for what cost, the inter- 
face system and/or the other systems and components involved can, or 
should, determine and present this status information ia cer4:ainly * 
a large question ^hich we only partially address in this study^ For 
the end user in a highly virtual mode ^the amount and detail of such 
information shoul'd probably be highly, limited. For an experienced * 



user and/or systems analyst the amount of such information might pro- 
fitably be very much greater. 

4.3.3.4 Verbose, Terse and O'ther SPEAK Modes 

In Section 2 we described the VERBOSE (longer, more instructional) 
and TEPSE (shorter) modes of the CONIT response language and how the-' 
are invoked by the SPEAK command ('speak verbose' and 'speak t^rse'). 
Two questions might be asked about the commands: 

(1) Why use a command and argument foriaat? VJhy not just 
two single-word commands; e.g., 'verbose' and 'terse'? 

(2) V/hy'the SPEAK coMand, in particular? 

Since these questions are generic — that is, they could b,e asked of 
many other linguistic decisions discussed in this report ~, we shall 
spead sore effort answering them here in hopes that these answers will 
also serve to' help explain the general case. 

The main reason for. the command name with argument format is 
to hejlp a user understand the nature of 'System functional capabilities 
through explicitness and consistency of format. This format mimics 
the verb-object/complenent/modifier form of English verb-phrase struc 
ture. The command name is a verb used as 'an imperative to the system. 
The arguments complete or modify the imperative. Keeping this format 
consistently is worth something toward user understanding even though 
some additional number of words in response or command language may 
be needed. Advanced users can readily resort to a more compact form, 

they choose. Thus, the one vord 'terse' — or even just 't' — can 
be translated in a particular user dialect into. 'speak terse'. Also, 
the system, in a somewhat more sophisticated parsing capability, can 
"undststand" that an argument word, when used alone, in^lies the com- 
mand v/ord (unambiguously) associated with it. [We may note, parentheti- 
cally, the relatively greater difficulty of this kind of parsing if 
short abbreviations (t) are used in addition to fuller forms" (terse) 
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because of the greater likelihood of ambiguity.] 

The choice of terminology , as such, ?:e].ates to several consider 
tions. Short, common English words as -suggestive as possible of the 
.associated function(s) are what is sought. Brevity, of course, makes 
for siitplicity, clarif, and ease of typing. .Common English words are 
easier to learn and remember. Of course,. the particular choice of 
words can be changed by a user for himself through synonym generation 
(renamAg) . verbs are preferred for command names; nouns, adjectives 
and adverbs for arguments . (Of course, the most common words usually 
have more than one syntactical class, but one may predominate.) Com- • 
mands, with their names, classifv the functional capabilities avail- 
able. Therefore, the choice of the word "speak" relates to a percep- 
tion — that we would _like the user to share ~ that the user/system 
dialog may have many modes and the user should be able to select the 
mode by asking the computer to "speak'-' in a certain way. The terms 
"verbose" and "terse" were chosen as- being somewhat more explicitly 
dialog-related than the other pair of' terms often used for this pur- 
pose: "long" and "short". 

Other dialog mode specifications would be made by other suit- 
able arguments to the SPEAK command. For the command language .itself 
we have used the arguments 'conif and ' host perhaps , 'directdy)' 
would be a better term than ''host'. System language names (e.g., 
"ORBIT", "DIALOG") 'and user (dialect) names (e.g., "smith") would also 
be allowed, some other modes possible are indicated in Sections 2.5.2 
and 3.4. Some of t .ese modes might more naturall/ be set other than 
by the SPEAK command as, for example, by "'pick' or 'set' (conitr 'mode' 
•automatic'." The language,^g^arser should be at least as tolerant 
to a user putting these arguments variously with the related commands 
as it should be to ignoring the command name altogether. 

The ordering of arguments in the SPEAK command, as elsewhere, 
should not matter, m faot, v;ith initial default settings of 'verbose' ' 
and 'conif, the inexperienced user should not have to use the command 
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ail. A renarang nacro should allow several modal argurrents to be 
expressed in a single term, for example, 'speak myway*, where 'myway' = 
* terse conit expository*. If tl^e user, then, implicitly asks for the 
sante irod^- twice — as in * speak terse myway' — the system should accept , 
the redundant elenent with, perhaps, a comment on the redundancy in 
ASSISTED mode. 

4.3.3.5 Renaming 

In order to modify the language for his own purposes a user 
snould be given a "rename" capability. One implementation of this 
capability is expressed; 

renam.e oldword [asT newword ' 

where newword, gets replaced by oldword by the system whenever it appears 
in the user statement. Note that this is a synonym-generating feature; 
the term oldword can still be used in its original sense. This may be 
contrasted with the situation where it is. desired to revoke the meaning 
of sore predefined vocabulary element (like 'and') so that it can be 
used.in^a different sense (e.g., as part of a controlled vocabulary 
term in a search). This latter capability can, perhaps better, be in- 
voked by the "quote" mechanism mentioned above in Section 413.1 in which 
the original sense of a term is removed in each instance that it is pre- 
ceded by (double) quotation marks. If it is desired to make the changed 
sense permanent, a different command should' be used ~ perhaps 'rename 
[ana] drop oldword (to) newword', with 'change' or 'replace' being possi- 
ble synomyns for 'rename [and] drop'. However, synomym genepting and 
literal (quoting) functions are generally preferred over re^/ocation in 
our virtual system approach because they allow users to fall back to, 
or more easily be encouraged into, using the common basic language ^ 
vocabulary and, therefore, inhibit the development and use of incompati- 
ble special dialects. 

The optional terms 'as', 'to' and ^axid: may be useful in helping 
t..- usor learn and remem>.er the language -construction at hand, expecially. 
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as in this case, where ar^gument order does matter.^ Of course, the re- 
sponse language shoiud be desigr)ed ,ca"ref ully to feed back the proper 
interpretation of what isf being done. In any case, the u e of tfiese 
optional English^ function words to make the command language look more 
like English should be carefully weighed against the danger that such 
* ^^^^^ ^ool the user into thinking the computer understands * 

English and (2) confuse the user by presenting him with additional 
vocabulary which the user might think, or suspect, that he is required 
to use. I 

The rename; function can be extended, in stages, to permit the 
incorporation of multi-word terns and spacing requirements as m the 
CONIT REPLACE command, and finally, to ,a full macro cpaability. , The 
more elaborate capabilities are certainly useful for a system designer 
(see Section 5); we shall not consider in detail here how inpo^tant they 
might be .for ordinary users and how much they might cost in terms of 
language sophistication. The macro translation capability may be 
symbolized in functional terms as: - \ 

[^1 (^1 ) . f^(x^) . . . f^(x )] ^ g[x. , , . . . X } 
11 2. 2. nn 12 n 

that is, a construction, g, containing variable elements x , x^ / etc., 
(^long with fixed elements) is replaced by a construction, g' , con- 
taining transformation's of the variable elements. 

4.3.4 Systerr^ and Data-Base Selection and Connection 

The use of the PICK command in CONIT to §elect systems and 
data bases was describi^d m Section 2. It wa6 felt that these two kinds 
of selections vere sufficiently similar to warrant using the same com- 
manc^. It should not be necessary to us^ the argument 'data' since, if 
the final argument is not in a list of known systems, it may be taken 
to mean ,a data base. 

* The word "pick" was chosen because of its brevity and de- 
scriptiveness ; other possible terms are "select", "choose", and "use". 
As was suggested in. Section 4.3.3.4, the selection of various types of 
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*r titles could be done m^er separate commands (cf. SPEAK)* or under a 
single ccnnaind; in the latter case we have the just mentioned question 
of whether we need to specify the different types by special arguments 
like 'data*, 'system*, or 'mode'.. The term *data' is used instead of 
*file' because it more specifically suggests the file to be searched — 
i.e. , the data base — as distinct from other files that may be involved 
ir. the retrieval. * 

The PICK command actually incorporates two separate functions. 
Thrr first IS the selection of a system or data base\^r searching. The 
3t^co:.'i 2 tne actual establishment of a connection to tJv^t system :or 
data base. For post situtions it may 'be satisfactory to perform both 
functions together. However, at times, as when one wants to avoid 
premature connection and extra co^, one may want to 'postpone the con- 
nection until the search is performed. For'this purpose, these two" 
functions night be separated at least by the interface' system if not 
'the user. * 

The selectipn of a data base may imply the selection of ^ system 
and the user should not necessarily have to perform, or even know about, 
the 3 stem selection. Sometimes the implication may be ambiguo-us (e.g., 
the nils and EPIC data bases are available through both SDC and Lockheed)'. 
In those cases, the interface may select which system to use,- with or 
without the help of the user, depending on whrch mode Vas in effect. 
Of course, with the Master Index and Thesaurus concept, it is possible ^ 
to ^jelcct the systems and data* bases automatically or partially so — 
fro^^ the search topic itself. 

In. connecting to retrieval systems the login protocol is 
gererjlly conceived as .being performed autopatically by the interface, - 

It is currently done in CONIT. However, in the more transparent (less 
virtual) ^i-tuation the user'* may need to assist in the login procedure 

V. ith identification and password. Also, the interface user needs 
to access to the interface itsel.f, probably through some^login 

procedure. Therefore, it is appropriate to consider what might be a good 
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common login protocol, even though we might be forced to use other pro- 
tocols currently. The general LOGIN command has the following syntax: 

login system systemname id userid pass password 

Several of these' terms could be deleted if not required in a given situa- 
tion (e.g., 'id' and 'userid*, if no particular user identification is 
needed for a given system) or if the variable element irrplied the argu- 
ment type determiner (e.g., -a system name implying the 'system' argument). 
For security and other reasons modifications to this command procedure 
may be desired. Discussion on this point is given by Neumann and 
in Appendix D v;here a more prompt-oriented protocol is suggested. In 
these discussions we riote that 'login' may imply a 'logout' of the cur- 
rent system whereas a 'logout' by user means "stop and disconnect termi- 
nal" and 'exit' means "return control to calling system." 

4.3.5 Search and Related* Functions 

4-3.5.1 Basic and Other Search Aspects , . , 

There are several aspects to searching that need to be consi- 
dered 'in the retrieval language: 

(1) System (s) to be used 

(2) Data base(s) to be searched . . . ' 

(3) Kind of file to be searched 

(4) Kind of data element (s) to be searched 

(5) Matching algorithm to be used 

(6) Elements to be matched 

(7) Combinations of elements * ^ ' 

(8) Type of results t;,o be reported 

(9) When to do the searching 
(10) Naming of results , 
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(11) Storijia of (partial and full) results 

(12) Sorting of results 

(13) Effects on previous searches 



The first question that mi^kt be asked wdth this large array 

cf considerations concerns how niafiy corranands are involved: one or thirteen 

or sore intermediate numbe?^' 

Clearly, sop^^^cf these considerations may be handled in separate 

'-orr^Lr.ds before a search comiriand, some in separate commands after the 

s^^rzr command, and some by default. The on\v one that seems necessary 

to t'--^^ search statement itself is (G^ : what one is searching for. However, 

it/^^ ^^irable to be able to include any combination of th^ other 12 

considerations within the search statement, if a user should so desire. 

\ 

A linguistic mechanism for so doing is simply to define separate commands 

for these functions which can also be included in a basic search command 
as v;e explain l^ej^ow. - ^ . , 

The basic search command is 'find searchstri ng'. where search- 
string is an argument or argument string expressing what term or terms 
one is searching for. The word ."find" is short, has good imperative 
search connotations,, and is commonly used. The word "search" suffers from 
Its ordinary usage in English: if you want to expre&s that which you are , 
searching for , the construction "search for x" is regularly used; on the 
oty;er harid "search x" is normally understood in the sense "search in. x" 
which in the retrieval application i,s best associated with the selection 
of a* lata base, or system, in which to search. The word "select" is not, . 
nearly^s spec^^^j^in ccnnotation fqr the search function. We have ex- - 
ildffPd in this report (Section 4.3.1) and in our previous report why 
we )fv^el there should be some explicit command name and not just ' search^ 
strirr/ with the default command being FIND'. 

4.3.5.2 Se lection of Data Bases, Files, and Search Element's 

■ — ■ — ' 

The d^-jfault situation for syste m and data base searched would 

: th(^ .urrently sqlecte^^ ones, unices otherwise* se^leoted automatically 
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through the Master Index and Thesaurus. The user could alsj make the 
selection within the FIND command as follows: 

find [pick] [da,ta] ntis radiation effects 
* > 

Note that 'ntis* is at the l^el of a sub-subargufhent. The (Command/ 
argument 'pick' — and *data', if possible — 'should be optional here. 
The se^archstring arguments are those arguments not otherwise identified 
as having pre-assigned meanings. The simple tutorial mode should sugge 
"PICKing" before "FINDing"; however, the "internal" ^election should 
be allowed so that the user (1) is not forced to -remember an orcfering 
requirement 'and (2) can postppne the connection as long as possible if 
there is no separate "select-but-do-not-connect" function (see Section 
4.3.4). . 

The kind of da'ta elenents to be searched may include elements 
lik^ title, abstract , descriptor or identifier index terms, author, etc. 
These elements would be given assigned vocabulary terms which would be 
used as arguments in the FIND command to specify the elements to be 
searched. Thus, 

find title descriptors neutron scattering ^ ' 

would signify a searc • for "neutron scattering" in the title or in the 
.descriptor index terms. The default condition (no data elements speci- 
fied)- 13*' to search -all data elements. (Ovtr general philosophy is* to 
be generous in- retrieval ?/<r.e • J enphasize recall at the expense of 
precision- — on the th^9ry that,Mt is easier for a user to weed out the 
false drops' tha^ 'to appreciate what has been missed). The general 
question' of what the common^ bibliographig. data structure should be and 
how it' maps into the "structui;'es found irj. existing data bases is dis- 
cussed in Section 6.2.4. 

,There may be several kinds pf^ files associated with a given 
data base. Searches arje usually^ done qn index ,( inverted) files. One 
may also search th^ full records .of th^' data* base, 'because a full rp- 
cord search must generally be done sequentially, it is generally done 
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(inly on a small subseit of the d^ta base — for eScaxvple /Ik retrieve.d. set . 
The index file has prtmaxry access data elements on^which searching can 
.be initiated and, sometimes , secondary data elements t^at can be scanned 



to deterrrine whether c. reference already found matches some ^secohdary 
criterion. Thus, for example, a document reference foiand (through title 
index) searching, to CDntain two particular title words may be scanned 

for secondary infor^natlion to determine if the two words are within a 

r 

':h other and/or if the document referred to is of 



C(>rtain distance of ea 
a given type, say book 

The user may , 
laxities. The user is 



or report, etc. 

:o a certain extent, be shielded from these coiji- 
instructjed to express each search in the same 
form with each data element type argument w'^thin the FIND command pre- 
cedinq its searchstrincj . As long as there is at least one primary 
access^ data element, U\e search can be programmed successfully; other 

instructed to recast the search with at least t- 
one such term. Sometiihes, however,^ — as when a data element may be 
Searched either as an index or a record "search - it may be desirable 
to specify wh.ch kind of file is to be searched. For this purpose the 
additional argument 'rscord* may be inserted before the data element 

full record: -1:h,us , e.g. , . . __ ^'^ 



to be searched in the 



siiiptor 



" find descriptor radiation record title neutron 

4.3.5,3 Term Selection, Combinations, and Matching 

The argument searchstring may include a combination of terms 
satisfying »a given Boolean relationship^; e.g., ' 

find A and B or C and not D • ^ . 

find A and (B or (C and^^not ») ) 

v/her'e A,B,C,'and D are terms which must appear ir^the stated combination 
m each document matched. The fcrder of operation is from left to right, 
unless countermanded by parentheses, as in the second example above • 
(Thus, the f ^rst/example is parsf^d * find ((A and B) or C) and not D»'.) 
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This precedence oi'der is preferred over one based on operator type 
because it is easier to 'explain to a user. (It might be noted parenthet 
ically that the f)recedence order often chosen — ANDing before ORing 
is opposite to the precedence inore natural to the retrievaA operation 4 
^first ORing" syr^'onyms for a given concept; then ANDing several concept^ !) 

The arjgument s^archstring Should not be taken to inply only .BJti \ 
exact string match is desired; other matching algorithms are also war7 
ranted. Nume/rcial data may be matched with arithmetic relations ;/ er;/g 

year greater than 1970, I ^ ^ 

String data can be matched in various ways; e.g., 

find record abstract on ?1 ifie : system r-^ttnau 

where # means any one character (two # for 2 characters, etc. J / 

: means any number of unspecified characters 'j 

7 means up to one unspecified character 

^5ore generally, we,, can describe a set of positional relation 
clqding^ relationships in word-oriented text; e.g., 

A within [exactly] + n_ units B within + n_ 

where units can be character positions , words, lines, seiftenc^s , etc. 

7 I 

n is the number of units allowed from A tqr B/ 

+ means B is to right, (follows) A 

- means B is to left (precedes) A 

+ (default case) means P may precede 6rl 

default for n is 0, i,e., A and B mvist be within the 
same (larger) unit ~ e.g., words in, d sentence 

exactly means only the specif ied /separation (nothing 
shorter) is allowed. 

Note how the earlier string matching operation symbols are abbreviations 




Thus, 'a##b' means the same as 'a within exactly +3 characters b'. A 



/ 



4.3,5,3 





orta^Jit ordering requiryertent is wor^ adjacency 
coj^enient yd^hzeviatedj form to express this is 
a 




within 1 word 

/\ 

ft-E^^ where the 

rries^dver its natutal language linkage si^/^fication* Lowe/ ^ 
s,.-6ake precedenc^in the ordering of t^ execution of retrieval 

, Lake 



ver higher order units which^ in>cum^ 



<:e precedence over 



combinatic 



IS. 
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/ As previous .worV has 'shown, /retrieval /results in general 

//^l/ettcr than for exact snatching can be obtained on word-phrase matching 

/when (1) word order \L ignored, comrnon woWf'^are/^xcluded , (3) only 

word stenc are rat'chjfed, and the^ Boolean Aj/d is'^assumed. Thus, a 

good system will t^e ^ ' / 

/ ^ ^\ / 

fin6 Grconpfriics of computer communications 

' ' . • / '1 ' ^/ 

and automatically up a search to match/on all documerlts havi?ig all 

three of th'e ste^ "econom:", "comput : '* , /pd "communi'<:at : in (any of) 
^^he inde^^ teoffe. Soijfe times , however^' better resu^s can *be obtained with 
^ a som^tiatyoif ferent! algorithm. The iiser need^ to be, able' to ^specify 

the variations. The 'within' argument ^tri'h^provides spB-cif^cation 
^^'^for wo^' order. The phrase / 

exactly (A B C)^ 



/ 

/;]^ch m^y be abbreviated '(^'BC)J 

user-given stem may be 
'find computer:^ woAild m^tjsrn "com' 



rationale for lising spe^i^, 




is that they are speo^l 
user. / 

' Other kin^/)6f automat 



Le desirab 
clusteroj^i 
Ijke v-yijtho 





sy;hb 



an/^ 




2S an ey^<tt match is desire^, 
coloi) convention; e.g., 
irs't but/T7^3%^^£pk(^tatLon. The 
the above /retrieval 
would not, be used by /the ordinary/ / 



/ 



int€ 



ila 



r^et;Lve matching /techniques may 
thetf;auri^Vfo^d re/Iated terms, statistical 
spejial ^ch^iques/ for special data el^rnents 
c^ttairf, initials /Anstead/of full nanifts// 



^tc 



^ Linguis/t^ devi/ces analogous to 
pej^;;:$^'^optrol tlri^sL/ fxmctiotls. 
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4.3.5.3 



Proposed command and response functions and related language 

features relevant to displaying the Master Index and Thesaurus were dis- 

19 

cussed in detail in our previous report. The command language il up- 
dated here to ii/with the newly developeQ- considerations: 



where 



Show type vocab data [ii lines 3 . te.rm 



term stands for that word, phrase; or string to 
be looked up ^ 

type stands for the type(s) of ^relations to be 
<^ displayed : 

' index* 



terms that surround term alpha- 



betically 



'phrase' — : terms having word stems in com- 
mon with term 



*thesararus* -- thesaurus relations for term 
' relations ' 



all of the above relations 
« 

vocab specifies the vocabulary (ies) that the ire- 
N 1 ate d 'terms must come from; e.g., Mesii, 

NASA thesaurus, etc. 

data ^ecifies the particular data"base(s) to be 

considered; e.g., MEDLINE, NTIS, etc* 

*^ • 

n_ lines specifies the number of lines to be dis- 
^ played. 

The default condition for type and vocab is all. ^ 

. . ^- 

The related terms displayed by this command will be tagged by short 
identifiers that ^ may be used to refer to those terms in FIND or SHOW 
type commands. 

A user may wish to specify the type of relation more specifi- 
cally as, fox example, synonyms or narrower (more specific) terms. Sub 
arguments to the 'thesaurus* argument could be used to make these speci- 
fications/ as 

show thesaurus synomyms t^rm , 
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A user may al^o wish to extend t^ie relationships found to more than one 
level in a single command. Thus^ to see the terms "tf^Tat are specific to 
a given term and the terms that are specific to those terms-, one could 
requ(^t * 

show thesaurus specific 2 levels term 

The user should, also be able to specif/ that certain thesaurus 
relations be automatically taken in^po account searching: i.e. ,xin- 
cluded in an augmented union set for each term. For example, 

find thes^rus' specific all (levels) term 

which IS equivalent to the MEDLINE EXPLODE command. 

Conversely, to suppress an automatic use of 'relationships 
user could insert a *no' argument qualifier; for example: 

' find no^ synonyms term * 

^ 1 4*. 3 ^ 5 . 4 . Res^alts: Naming, Combining and Re-searching 

The result of a search is a set, or list, of documents. These - 

\ 

sets are autoipatically giv|n name^ of the form\^et 2' , where j_ is a 
nijmber assigned sequentially. Alternate forms by which to refer to these 
^ts should be ' set j^' .(no space), and, where ambiguity can be avoided, j\jst 
the number j. The fuller form including the word "set" felt to be 
more descriptive*" for the inexperienced user and offers less confusion 
with numbers used irl other ways. Of ^course , the user can always re- 
rame the sets to suit his purpose's.* A convenient way to do this for 
the current s^t is with^ the command 'name set' 'or just 'najpe'. Thus 

find computer 'network's name cnet 

is equivalent to ' ' 

find computer, networks ; renarre set k cnet 

•where *set k* is the current set name. • * 
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* Intermediate results may include counts of numbers of documents 
found under, in-dividual terms and partial combinations of terms. To see 
tjjiese counts the Command 

show count' 

is employed. If the command were included within the' FIND command, the 
counts woul$i be shwon as they were found; if the *shov7 count* command 
caive .separately, the partial results ^uld be shown after the final re- 



suit. If the final result is null, it has^een found effective ^ to 
provide the intermediate results automatically to- the user; tHat could 
be overriden with the .argument string: *no count'. The intermediate 
sets themselves should be kept at least until the next retrieval opera- 
tion so that a user can make toy of these aVecognize^, named s§t with- 
out having to reproduce them. - / 

^ ♦ 

Regularly, the final results from ^ search as s^gwn to the user 
would include (1) a restatement of the search query (showing automatl<^/^ 
stemming and phrase decorrposition , if performed) ; (2) thfe count of the 
number of documents found; tod (3) the name given to the newly found 
3et. Internally the system -should store the above information for each 
search together with additional information such as synonymous set 
names; the aotual list of references retrieved; and, at least implici't;ily , 

'♦V ^ J 

the system (s) and data base(s) searched, the date and time searched, r 
and the identity of the (human) sear^her^ This infonhation would be 
available for user review by the command: 



show sets [mode] [se^ if^ [set 



where moHe would /specify if more of»le^s information than the 3 items 
firat listed above were desired; the particular (rang? of) sets to be ^ 
reviewed, if other than a full listing were desired, could be specified* 
by th*e otl^e A' d'rguments* A good synonym for 'sl^ow sets* might be l^review*. 

The user* may want to delete some of the set;^ he has 'made jeither 
because they are too 'costly in storage (a system may actually limit the 
number permissible for this reason) or because they are cluttering 

' 1- . 
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up his" "thinking space". A DELETE command would acconc)lish this: 

delete set i_ set 1 • • • . 
To delete all setS: 

delete all sets 

To delete a certain nun±)er (or all sets numbered before (less than) a 




delete' nul*ier direction set i 
\ — -^ r v ■ ~ 

wher^ nun^ is a given number or 'all'; direction is either 'before' 
or 'after'. . To renuntoer the Sets in the same order but "closing up the 
ranks" f^r the deleted ones, the command would be: 

rename sets 

For this command the'' synonyms for the set names would, of course, be 
transferred with the. set 'to the ne^ set number. . 

RetrievecJ, search sets may be combined using a COMBINE conman-d with 
Boolean operators and set names in a way analopus to the u^e of these 
operators on terms to be searched in the FIND command. Thu^ , e.g., 
■ * ' '-^mtoine (set 5 of set 6) and set 2 and not set 7 

creates a new -^t with the spepified relationship , to previous sets. 
%^ \ (Note that the pa^heses in the example are W necessary since the 
■ same left-to-righf precedence^ would have been followed without them, 
in this case.) Again, we recornnend* insttucti'ng users with an explicit 
COMBlf^E command name; expressing the combination function without a • 
conmand name should be an. option for more experienced users. When sets 
• are components ot other sets there is -a question of how many levels to 
unravel this structure in the REVIEW command. 

The user should be able to intermix searching terms and combining 

sets. Thus, e.g. ; , - i, 

find energy costs and not set 4 



4.3.5.4 



should be allowed. Extending thhs idea slightly, we sep that COiMBI-NE 
cormnand would not he needed at all; thus 

find set 5 or set 6 

(Note that this iirplies the system can distinguish set names from search 
terms.) Boolean operators should also be implicit FIND commands with the 
current retrieved set understood as the starting point; thus 

and year greater than 1970 

should be mterpretable as meaning 

find set k and year greater than 1970 

where 'set k' -is the current retrieved set. To make" any set the cur- 
rently active retrieval set the RESTORE command can be used: 

restore set 2 

The command name '.restore' should not be required; thus, the above 
would be obtained also by . -T 



set 2 




''If a retrieval or comb'inaiion function results in a null set, the last 
previous (final) reprieved set would remain the current set. 

It may be desirable to re-run a search statement after a data base 
update or in an entirely diffelrent data base. Adding the argument 
'research' (immediately) before a set name would signify that the search 
statement was to be re-rxin rather than use the set itself. For example , ' 

find research set 4 and not set 4 . 

m 

would perform the search originally performed to get set 4 in this new 
context and then drop out those documents that were in the original 
set. Since this is likely to be such a useful function it is worth 
a separate command: ' update '^set i_' . ^ * 

Normally, a search statement is executed right a* ay - that is, 

I 

as quickly as the time-sharing system gets around to it. However, m 

X 
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ar. optinized system the user should be able to get a delayed execufiion 
for lower cost. The user should be able to set up a sequence of sftate- 
ments to be run m this background mode. An irtportant related retrieval 
function is SDI; that is, the runijmg of a search automatically at each' 
data* base update. We shall not discuss further, here the various lin- 
guistic requirements for specifying the setting up and running of a 
program and obtaining the results. 

4.3.6 Output and Related Functions 

Tne output function refers to the printing or displaying of in- 
formation from the catalog records — or full text, if available — of 
documents in the data bases. The specifications, that may be necessary 
for the output function include: ' - 

(1) What information (data elements, etc.) to be output 

(2) For what document set \^ 

(3) For what documents in the sets 

(4) Where in formation .is to be output 

(5) When information is to be output' 

(6) VThat format for output 

(7) What sort order 

The basic ouput command is 'show*. No arguments are required since all 
the specifications have default conditions. To specify otheir than the 



default conditions arguments are required,. as described below. In 
general, the ordering of the arguments i^ immaterial, except as noted. 

The data elements desired are indicated by a string of arguments; 



e.g. , % 

' - show- title author abstract 

It of ten d^3^s'irable to express a grouping of elements 'jy a single 

term. For example, 'all* for all elements (the whole catalog record) 

>4 



'3nd 'citation' for those elements providing the minimum reference in- 
formation (see discussion in Section 4.1 — we would reserve the term 
'references' to mean bibliographic references in the given document to 
other documents and 'citing elejpf^nt ' to mean a data element' from a 
document that, cites, the given document.) The 'citation' group is pro- 
bably -b^st as the default set of elements. 

^ Other kinds of irtfor'mation besides data elements, as such, may 

be called for if the system has the capability. Thus, 

show text, 

could call for a display of the full text while 
show match 

'could ^call for output showing why each' document was matched — e.g., 
by "highlighting", those words in title or abstract that match the 
search statement! 

» « 

'To specify which set ^one. wants to outppt the natne of that set 
is used as an argument: 

show set 5 

In the default case the current set is assumed. Also, in the default 
case it is assumed that all documents in the set are wanted. To select 
« a subset of the documents the argument 'documents' ^abbreviation 'docs' 
or 'doc' ) is used: 

show abstract documents 3 7 to 10 15 

gets the abstract for the third, seventh through tenth, and fifteenth 
documents in the current set. The connector operator *to' could be 
replaced by a hyphen. ' 

The 'documents' argument can be used with the FIND command to 
generate, a new set that is a subset of the current. Thus, 

find docs 7-10 

will create a new set with 4 documents from the current set. 



4.3.6 



It IS assuiced that a user can interrupt the output any time. 
If the system does not permit interrupting, or if the system wants t6 
avoid an excessive amount of online output, it may stop the output and 
ask the user if he wants to see more. The command 

L show more ' • 

would be a positive reply. The arguments 'from* and 'after' would alsa 
be used to indicate that ali doc^airvents after a certain number were 
wanted; e.g., 

show from 'doc 7 

A user on seeiijig a title- for a given document in a string of 
document titles might want to see more information on that document. 
The user could do this by in-terrupting and then issuing the following 
commands : ' • 

sHow abstract document^? 
show title from doc 8 

'*■ 

To add document 7 to a special saved set^ before continuing the user < 
could issue these commands: 

find doc '7; or saveset; rename set k+1 as saveset; 
show set k title from doc 8 

where 'set k' is the current set. In order not to create the super- 
flouous set k+1, a comjnand 'keep* might be defined; e.g., 

keep docs 5 8-10 (in) saveset 

v/ould add 4 documents to set saveset without^ creating any new set names. 
If ' saveset '^were not names-, a systems-defined, default set: wo^d be ^ 
assumed. j 

To specify a different document order than the one provided by 
the systern^ usually an (approximate)' inverse chronological order — 
the ORDER argument is used: 

s^ow order field mode 
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where field specifies the element or group of elements to sort on: . ^ 

mode specifies the mode of sort; e.g., forward or reverse . 

The'output format would depend in part on the SPEAK mode: VERBOSE 

h ^ ' • 

being more explanatory about what tHe -dement fields are. Ot^er formats 

would be specified by other arguments to the SHOW command. 

The default situation has the output going to the user at the 
terminal. To send output to be pisinted offline the argument 'offline* ^ 
, would be used in the SHOW command. The address to which offline out- 
put should be sent should be stored by the system; gettin-g^the in- 
formation about the different parts of the Address appears to be 6ne 
situation in which the pronpting mode has advantages. As with the 
FIND command, there jnay be various levels, besides offline, of delay 
in the execution of the SHOW command. . . * 

4. 3; 7 Instruction and Status Review 

< 

We have previously discussed the 'help' and 'explain concept' 
commands and some other facets of the^ instructional features of the 
retrieval language (see, especially Sections 2.1, 3.3 and 4.1). Some 
additional features desirable to enhance instruction ^are discussed in 
this section. 

• The command 'Explain'' without ^y arguments can be taken to 
request an explanation* of the last message or cufrent -content . The 
command 

explain message 

can be taken to request explanation of a given message or message com- 
ponent identified'by the argument message which could be a prefix of, 
or a tag associatedVwith, the message. 

The user should be able to "turn off" lengthy instructional ^ 
messages once he has seen* them enough to learn their message- The 
command 

speak message terse 

.89 
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would request this. The command 

speak message verbose 

would reverse the setting and * explain* or 'explain verbose* or * ex- 
plain message verbose' or 'explain more' would give the fuller ex- 
planation at the current time without actually resettij^^^T the VERBOSE 
mode. \ 

According to the sinple-basic-core principle the user should be 
shown only a few basic features to start with. However, the system 
should occasionally projnpt the user to ^ry additional feature?. To do 
, this effectively the system should keep^ track of what features the user 
has employed and explain, in appropriate contexts, additional features , 
that might prove useful. This dynamic instruction would bef guided / 
as the whole interaction is, by user mode settings and Specific requests. 

Online human instruction would, be valuable at times ^ although 
perhaps xcostly. To invoke such help one -might use thd command 

help huran 

after which a free-form dialog between instructor and user could ensue 
in which the execution of regular commands would be 3uspended until 
the- regular mode were reinstated. ' ^ 

More generally, the user might want to communicate with other 
persons via the computer. A message-sending command might have the 
following syntax: * * 

send mode to name address message message 

wliere naine and address , tell where to send the message 4 

TOde expresses a mode of transmission- — e.g., immediate or 
offline 

message is the message itself — which could come- from a file 

rather than from .the command line . 

Status information would be provided to the user as part of the 
regular dialog and in response to cer4:ain EXPLAIN and SHOW command 
options. Many kinds of status informatori have §ilready. been discussed. 

90 
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Sone specific status thaV can be, or should be, available, may be 
listed: * ' ' 

f 

(1) systems potentially* an^ currently available; 

(2) date bases potentially and 'currently available; 

(3) dialog^ modes currently s^et; 

(4) cumulative and incremental time^ and- cost considerations. 

4,^.8 Saving, Sharing and Reviewing Results 

One area that current retrieval systems ar6 just beginning to 
develop is the saving, reusing, and sharing of search results from , 
one session to another. To ^ave a retrieved set a saved file may be 
opened: 

open file 

where file is the name of a previously created or new file. Sets may 
then be saved in this file > with the SaVB command: 

save set j set k 

The information about the sets mentioned in Sectidn 4.3.5.5 should be 
kept in the saved file. In fact, sometimes it may b^\desired only to 
save the search statements. These sets may then be used in subsequent 
sessions ijiy their creator, or someone else with the creator's perrrission. 
As a' further aid in recording and communicating results the saved sets 
and files/Vhould be, annotatable by the users. 

To^, distinguish two sets that may have been given the same name 
it may be necessary to prefix their given nar^es with some of the status 
information. To. restore saved sets or files the RESTORE command may 
be used: • 

restore file [set i] [set k^] 

where all or, opti^onally, some of ^he sets ^n file are added to the 
current file fTOm Which they may be used in the -same ways as sets , 
* created durifig th^ current session. 

Two other kinds of saved files may be useful. Storing the inter- ^ 
active dialog in a monitor file can be useful f^r systems analysis and 

. ^ 9x 
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as a reans by which the user, ^especially a user at a display terminal, 
can "page back" to see previous dialcvg. It may also be useful to store 
the output from various searches in a common file as is now done in 
CONIT. The monitor file would be automatically updated, if used at 
- all. The output saved file -would be opened as the other saved files 
and would be updated by the use of the argument 'save* in the SHOW 
command. A VIEW command would be used to display from these files; 

view^ [ file ] page n' 

where the previously used file would be assumed if not expressed. Other 
examples: ^ 

view certain [page] 

whe^e certain = -last, next, previous, first, etc. 

y 

^ 4.4 Summary 

* We have described some specific plans for a common retrieval 
language based on certain principles of user/system interaction and 
desired features of interactive lang.uages. Having examined the probj.ems 
of using unrestricted English as a common retrieval language", we have 
tried to determine the general and particular features of a language 
that v;ould be simple, easy-to-use, extensible and containing at least 
sor^^^ ^he elements of English that appear helpful tor interactive 
dialog. The' language is intended to have an "open" format and make 
use of thfe'^b^t features of existing languages. 

The language as >d^scribed is neither final nor complete in that 
3t be tested and many additional functions may be required. We 
ha\/e^ t^ried, however, to (1) suggest the variety of functions desirable 
/ in a retrieval system (2) rai^e issues with 'respect to the linguistic 
feal|ii^es to express thos^ functions; and (3) suggest some particular 

these issues. It is .noted that answers depend as much on 

what s^^of functions^ is decided on in any given, implementation as on 
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5. MESSAGE INTERPRETATION AND PROTOCOLS IN AN INTERFACE 

It 

« 

Our experience with the design, implementation, and evaluation of 

^ / 

the experimental interface, CONIT, has led us to a clearer understanding 
of what functions need to be performed by a translating interface m a 
computer network situation. In particular, we have been led to consider 
the character of the timing and translation of messages among the i??tter- 
actmg but 'independent and heterogeneous processes involved in the 
interface operations. One special character of this interchange 'derives 
fror. the fact that although the mess'ages coming from the retrieval systems 
were designed for human interpretation, in this situation they are actu- 
ally interpreted by a computer process: the interface. 

We hope that our characterizations may lead to the development 
o'f a model that will be useful for aiding in the resolution of three 
kinds of problems in the. airea of networked interfaces. The first problem 
^is an adequate general characterization of message handling functions, 
timing, and translations for networked interfaces. The second problem 
is the design of mechanism for conveniently describing the actual messages 
to be transmitted from a specified common interface to particiiLar re- 
trieval systems in response to specified conditions and messages from 
the given systems and from a user. The third problem is the design of a 
software structure which provides an effective and. flexible mechanism 
fer carrying out some major part of the interface functions as specified 
by some mechaji^:^ such as one associated with problem area tv/o mentioned 
above, wg'shall discuss the utility of the model for addressing these 
projariems after describing the model. 

5.1 Simple Model * ' ^' V 

We shall first describe ''our initial formulations of these prob- 
lems and their shortcomings. For most retrieval systems as for most 
comxjiiie^f--s7s5iws that worK in an interactive, time-sharing mode with, 
human u^i^<cs — the usual^ accepted basic mode of operation is"tnie<in 
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which each party in the dialog — the human user and the computer system — 
takes turns in sending messages to the other. Thus, typically, the user 
first makes a/request of the system; thenjsi^e system interprets and re- 
' spends to tiPie user with some message of its ^wn. This cycle of non- 
overlapping, sequential messages* is repeated after the user, having 
waited for the conclusion of the message from' the system, digests that 
message and decides on his next course of action — which is expressed 
as a second message to the systei^ This sequential mode is illustrated 
diagratnatically in Fig. 6. 

The extension of this simple sequential mode 'of operation to the 
interface situation is diagrammed in Fig, 7.^ In this mode the user 
in each cycle first sends a message (Ml) to the interface; then the 
interface interprets this message and translates it into a request to 
the retrieval system (M2) ; neict, the retrieval system sends its response 
(M3) to the interface which, finally, translates it into a response (M4) 
to the user's original request. 

Three modif icatipn's to this simple 4-step cycle may be enumerated 
which will make for^ a more realistic model of the necessary interface 
operations. In the first place, the interface might well respond di- 
rectly to a user request say, a request asking what systems are 
accessible from the j^erface — without need to go-" to any retrieval * 
' system; thus messages M2 and M3 would be short circuited in this case 
by action purely local to the interface. Secondly, any such message' 
M4 from interface to user might be intecrrupted by the user sending 
an "interrupt" or "break message", the interrupt would occur during M4 
aiid cause the interface to stop sending M4 immediateT.y and "^o return 

— ■ — i- »■ ■ 

*Typically, .a user issues a "command" and .the system returns with a 
"response" message. However, the system can -also "commajidl^ a response 
from the u^^er, who may also wish simply-* to send an informative message 
(e.g., gripe) to the system. The general term "message" will be used 
to cover all these situations; different message types will be indicated 
as needed. / 
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FIGURE 6 TIME DIAGRAM OF USER/SYSTEM MESSAGE FLOW FOR SIMPLE 
SEQUENTIAL OPERATION • / 
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.FIGURE 7 TIME DIAGRAM OF MESSAGE RlJw WITH INTERFACE PROCESS 
FOR SIMPLE SEQUENTIAL OPERATION 
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to a state awaiting furtlier user requests. Thirdly, one type of user 
conrrand nessage would be to select a different retrieval system for 
searching, thus several retrieval systems could appear sequentially, on 

different cycles, as 'the recipient and t-ransnu-tter , resp e ctively, of 

^ messages M2 and H3. , 

This modified sequential' model corresponds generally to the y , ^ 
basic structure 'of our early experimental interface , 'TXNIT . Also, as 
we have mdioated in our description of CONIT in Section 2, a simple trans- 
lation scheme was irrclemented in which a pair of translation tables was 
devised to effect the translations for each retrieval system: one table 
to translate user input to retrieval system input (message Ml to M2) and 
a second table to translate retrieval system output to user (message M3 
to M4) . This translation is a straightforwaird conversion of specified 
strings from the input character stream to "similarly fixed and pre- 
specified output strings. , ^ • ' 

5.2 Limitations of Simple Model 

. We knew at the outset, of 'course, that these sequential opera- 
tions and simple translations would not suffice 'for everything we might 
wish the interface to do; the degree to which^ they were effective and 
the particular ways ixi which it turned out they were insufficient provide 
a valuable, basis for analyzing the complexities of the interface situ- 
ation. Some of these complexities are discussed next. 

5.2.1 Interface/Systems Dialog Unmediated by User 

A single user request may require a series of interactions 
between the interface and a remote system Tatheif than the single pair 
of messages M2 and M3 implied by the simple model/ An. important ex- 
ample of this occurs when the user requests the selection of S new 
system through the PICK command.' Here the interface must go through 
an extended exchange of messages with the»retrieval system. Even with- 
in the limits of a single retrieval system a series of messages may 
be required. For example, an output request by a user which selects a 
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discontinuous subset of documents, to be output (e.g^ SHOW DOCUMENTS 
I 4 7-9) ray require a series of output r^^quests be sent to a system that 
cannot handle su^rh a request in one command. . , ^ 

~ " ' In some instances it;^may be des iraBTe^tor tne iirt~err^ce"f^6 initiate 
an* interaction with the retrieval system without any explicit user re- 
quest. For example, a retrieval system may drop a user who does ^not re- 
act with the system for more than a given amount of time — say 15 minutes. 
It IS desirable .for the interface to keep track of status information 
like the time since the last interaction. The interface ccruld then send 
a s'--rle reauest (e.g., asking for the tire used in current session) to 
forestall the line dropping v^^ile checking the status of the connection - 
to the retrieval system. 

5.2.2 Indefinite Kature of Systems Response 

The general nature of, and particular realization of; system 
messages m.ay be difficult to predict' for a variety of reasons as out- 
lined belov/: 

(1) In general, it may be difficult to know the precise 
nature *of the respojises to be expected from the 
retrieval systems. Retrieval-system designers devise 
t^e response repertoire of their system to be largely 
sel f-explanatory- to a human user. To the extent 
that they' are successful — or believe so ~ they may 
not .feel the compulsion to fully describe these re- 
sponses in any written documentation like, for example, 

' a user's manual. While the common message types may 

b^' fairly easy to uncover, messages for special situa- 
tions (e..g., error conditions) may be very difficult 
to learn about through the standard inquiry channels 

' of (1) written documentation, (2) informal communi- 

cation with system designers or users; and (3) ex- 
perimentation with the system itself* 

To compound these problems the retrieval systems are 
ofteft^very dynamic in their construction — especially 
I in regard to the system-to-user dialog. It is not un- 

usual for any given system to experience several changes 
of this kind in the course of a month — often with no 
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prior warning, or only a very general notice per-- 
haps to the effect that a "new systen" is "about 
to appear." A change in the logoff rr.essage, for 
e^anple, may seem innocent enough and be easily 
understood by a human user but could cause serious 
problems for simple-minded computer algorithm that 
was leoking for one fixed string — say, "LOGOFF" — 
and finds another — say, "system disconnected." 

(2) In particular it may' b;e difficult to know when a . : 
message has been completed. Usually there is a 
"user prompt" which is a particular string of char- 
acters .that signifies that the message from the system 
is coippleted anc the svstem is prepared for a new 
message from, the user. However, sometimes a system 
may depart from this scheme, for example, when it 
asks. the user to respond to a particular question — 
say, "Do you want to continue printing output?" 

The difficulty of knowing wherv a message is* completed 
is c9mpounded by the stochastic nature of the messages: 
bercause of the inherent character of time-sharing 
systems, messages may start being transmitted at some 
indeterminate time, may be interrupted temporari-ly 
for another unknown interval, and be concluded at a * 
time of similar indef initeness. The interface- must 
wait a reasonable amount of time before concluding 
that no further message is coming from't^ie system ^ 
but it must not keep the user waiting an unreason^ 
able amount of time either — see discussion on re- 
sponsiveness in Section 3. The appropriate timing" 
of time-out signals for the interface and what message ' » , 
to the user and other functions should be performed •> ' 

at these times are^ clearly important issues. 

(3) Variaifle Messages. Most me'ssages, or crucial parts 
thereof, are variable in content by their very • 
nature. Messages of this type .include: * output about 
documents; the message telling how many, if aiiy, 
documents were fouhd in a search; and news given ^t 
login or in response to an explicit request. 

5.2.3 Unexpected or Unpredictable Messages . Communication 
channels can g^erate erroneous transmissions. Moreover, computer systems 
can and do get sick and die at .unpredictable times. The messages re- 
ceived from system^channels at such times can vary from (1) nothing 
(there may be a simple line dropout with, or without line-disconr|e^ct 
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•notice) to (2) sU.gV5tiS^ ^£s fpj^e^. irissages to (5>-^i^rish to (4) "wrong" 
.^•6$ages (as wherv' responding to transrissioR-caused "wrbu^Ucqtrmand to 
•< (S)* a ir^essage stating the time of initiation and expected dtoation of an 
outage. These latter messages may be of a well-specified fonr- or may be 
.completely free form. At, such occasions the control of message response 
.from system channels may change. For example, control may shift fror-.. 
a irettiov^l syster- to a time-sharihg supervisor (e.g., IBM TSO) or to 
an intermedi'ate network through which connection to the retrieval system 
was arranged (e.g., TYMSHARE or ARPA netv.-orkV. Such changes of control can 
dictate correspqhdipg changes in message ft?rm (e.g, e]?d-of-message in- 
dication) and message content (e.g, a line dropout indication as opposed 
to the expected resportse to a previous command) . The interface must be 
alert for 'these possibilities, try to diagnose them correctly, and be 
prepared to act appropriately. 

.5,2,4 Overlapping of Messages. Contrary to , the assumption of 
strict sequentiality in messages' made in the simple model, there is need 
to consider a high potential for,' overlapping messages beyond just user 
interrupts. Because of the variable nature of system responses in terms 
of timing, length, and content, it is important to consider taking ad- 
vantage of the full-duplex potential of the communication channels. For 
exa^iple, it is necessary to be prepared to accept and react to an un- 
' expected message of the type mentioned in Section 5.2.3, above, which 
' could occur^ while the interface is sending a message to the system or 
is 'interacting with the user. Furthermore," there is ^the possibility of 
much* greater efficiency and- responsiveness to the user if the interface 
is capable of interacting wit* the user while it is also doing so with 
a retrieval system, especially where long interactions are involved. 

For example, the interface should keep the user informed, during 
the long connection process of success or failure ~ or, especially, 
tha.t intermediate situation that frequently creates uncertainty and 
anxiety .in. the user: delay. (S'ee Boies for discussion of how "time 
uncertainty" adversely affects users.) Also, for efficiency and to avoid 

* 

1-QO' 

-92- 



5.2.4-5.3,1 



delay, the user should be given the initial parts of responses from the 
retrieval systems, as for docuirrent output cr news messages, while those 
responses are still being" received at the interface. ^ 
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5,2.5 Multiple Simultaneous Retrieval Systems 

mm 

It may be desirable to search several retrieval systems at the 
sam^ time or, at least, alternately and in such close prcxirity that it 
would be inefficient to login and logout for each search. The ultimate 
interface system would provide for the simultaneous searching of m>ultiple 
data bases wherever they may exist so as to allow for greater respon- 
siveness and comprehensiveness of retrieval function for the user. ^ 

5. 3 Towards A More Com.prehensive Characterization 

The limitations of the simple^.model described above in Section 5-2 
led us to consider what elements' would be required in a more comprehensive 
and adequate characterization of message communication in a networke'd 1 
interface. This section includes the beginnings of such a more compre- 
hensive characterization. 

y It should be rem.en±.ered that the interface we are considering 
connects a user to existing, independent retrieval systems without re- 
quiring any change in these systems. If standardized network retrieval 
protocols were devised, and if retrieval systems were modified to adhere 
to these stcfndards, mainy of the problems ve have been desc^febing could 
be circumvented or, a't least, handled in a fairly straightforward^ way 
as we shall discuss in Section 5.4. However, it is well to consider , 
the complexitires as they now exist because (1) in so doing we m^y 
help point the way toward and 'encourage standards and (2) we may never, 
or not for a long time, achieve the needed standardi . * . ^ ^ 

5.3.1 Communicants and Communications . 

The kind of network we are investigating is characterized by com- 
municants sending each other messages. A message i:^ generally either 
(1) an imperative — i.e., a request for some actioij expressed as a 
command — or (2) a response to some imperative. Hdwever, an unrequested 
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declarative — e.g., "The systems will be going down in 5 minutes" — ' 
or other mixed types are possible.. Even a declarative is often an implied 
kind of imperative, e.g,, for ^the previous example: "Please finish up and 
log off in 5 minutes or your session will be terminated (abruptly) by 
the system" . 

The communicants for the interface situation are (1) the interface 
itself, (2) human users, and (3) computer-based retrieval syst^s, and 
occasionally (4) , other computer ^s^^err^ like operating system.s for 
individual computers or network communication processes whose function 
in the retrieval application is. to establish and maintain the connection 
to the retrieval system. We ate'/ in general, interested only in those 
types of ^messages that would be'^generated by, or intended for, the human 
user in the course of the retr:(-eval "Application. We are not, for 'our 
present purposes, concerned w^tJi the lower-level, inter-process and inter- 
system protocols upon which theC^i^igher-lev-gl , human-oriented message 
flow takes place. Thus, we at'e'not concerned with that "communications 
subnetv/ork" of minicomputer processors that provide the inter-computer 
communications nor with the protocols among these communication pro- 
cessors or between the communication processors and the host computers ' ^ 
on the network in so far as all these protocols are essentially trans- 
parent to the retrieval systems and^human users. 

5.3.2 Communicants as Rule-Governed Processes 
X 

The 'comr.uricants can be viewed as processes which generate, inter- 
-pret, and respond to messages. We would like to characterize the rules 
by which this interpretation is (or could be or should be) done. One 
kind of rule has to do with the time during vhich communication will be 
accepted. A second kind of rule concerns the protocols for a message; ' 
what format it must have, what signifies that it is completed, etc' A 
third kind of rule concerns the actual rules for interpretation and 
response to particular messages. The most comprehensive level of concern 
with respect to rule execution has to do with the data, both data internal 
to the communicating process and external events, upon which the rules are 
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applied in order to determine^ the particular - response messages. 

All these kinds of rules are, for the interface itself, open to the 
determinations of the interface system designer and rray be optimized by 
him with respect to his chosen parareters only under the constraint that 
the other processes are suitably respected. With r^^ect to the retrieval 
systems, the rules are largely fixed and, under the guidelines of our 
approach, not und^ interface control. The one major excepti^jn to this"^ 
lack of control is that most systems will have two or more modes of opera- 
tion in which the output messages — and, possibly, the input commands — 
may take different forms: for examtple, a short form for experienced users 
and a longer instructional form for inexperienced users. The "^interface 
can set this mode and, in general, would choose the more compact form 
for efficiency. , . * 

Knowledge at the interface of rules at the retrieval systems varies 
with phe type of rule. Knowledge of timing and format rules generally 
can be well established. Rules of interpretation and response can be 
known in general terms subject to the limitations mentioned in Section 
5.2. Actual responses cannot, in general, be predetermined since they 
often depend on the detailed cocitents of the c3ata bases. Except for 
interaction with the index files in an implementation of our Master 
Index and Thesaurus concept, i^esnonses to messages involving interaction 
with the data bases can only be known a posteriori by observing actual 
responses . 

Knowledge of the human user ais a rule-obeying communicant is much 

less well defined. As an input device the human can accept, a wide range 

of timing and format although, depending on the user, some formats are 

likely to be more 'effective than others. As an output* device the user * 

is forced to accept the format that the interface demands; i.e., the 

common comjr.ar.d language. * As a rnessage interpreter and responder the . 

18 21 24 35 3 7^ 

individual human is largely an enigma, although studies ' " ' ~ 
have shed light on the nature* of typical users.' However, the interface 
can strongly influence the nature of the Response through instructions,' 
suggestions, and parti6ular queries to the user. 
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5.3.3 Structure and Timing gonglbd^rations * X 

The network structure has the interface itself as a mediator. be- 
tween a user and several interactive information systems.' Thus, a dia- , 
gram of our extended model, shown in Fig. 8, looks struct'Urally similar 
to that of the Simple Model of Fig. 7 with the main difference being the 
explicit recognition of nultiple, simultaneously-connected information 
systems. It is also recognized that any connected *'infcrration system" 
IS not necessarily a single, monolithic system but can appear to the 
interface at various stages of the dynamic networking process as a net- 
work connector or a host-computer operatang system. Generally, when the 
interface has established connection to the retrieval system these in- 
termediate stages become transparent ^nd lean be ignored until a dis- * 
connect — either intended or accidentiall — causes them to reassert 
themselves. 1 



It is worthwhile, parenthetically. 



to consider the question of 



multiple, simultaneous users. This multiplexed situation clearly would 
-be part of any efficient operational interface- form of networking. How- 
ever, it is quite conceivable that the multiplexing needed ^to handle 
multiple users can be accomplished entirelv — or, at least in large 
measure — by the systems and networks in which the interface resides 
or to which it is connected to. In any casle, the issue of multiple 
users is e separable one. 

An important qeneifalization to the simple interface model is in 
the area of m.essage timing. As was pointed put in the previous section 
(5.2), we want to be abl^ to consider a considerable ambunt of over- 
lapping in time among messages. Basically, messages from either user 
or any system are conceived as arriving at the interface at some later 
time. Conversely, while messages are being received, the interface may 
be sending messages to any combination of systems and- user* 

However, in the retrieval application the timing of the reaction 
to messages is usually not too critical. In particular, the interface 
can generally wait a minute pr more to respond and still not cause any 
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proDlen^. In general this means a message can be interpreted and~"re- 
sponded to before considering any other messages that may have arrived 
after the arrival of the given message. The most critical timing is in 
the login phase because timeouts may occur if responses are not Jent to 
some messages within a period of the order of a minute. Ir ordef to 
avoid such timeouts the interface can be prograinined to follow through 
with the login to one system before starting another login or reacting 
to a message from the user or another system. 

Occasionally, it may be desirable to hold up the processing of one 
nessage until an incoij|iing message is completed: for example, a user 
command to stop waiting for a response from a retrieval system if that 
response is just starting to arrive. 

The fact that a message is initially interpreted does not nec- 
essarily mean that the full response to it is given at that time. User 
interupts , for^xample, may simply be nQ4:ed for action at a later time, 
perhaps, w[hen an ongoing operation is completed • This situation can 
be discussed further after we describe in greater detail in the following 

section that nature of the rules to be followed by the interface. 

r 

5.3.4 Message-Handling Rules for the -Interface 

The rules for interpreting and responding to messages at tlje in- 
terface can be thought of as operating on input message streams and 
generating output , or response , messages. One generalization over the 
simple model is that response messages may be directed to more t^han 
one comm.unicant as the result of a single rule — typically, say, to 
the user and the currently active retrieval system. 

Another major sophistication for the rules is that they be context 
sensitive through the mechanism of state variables ^ Thus, in addition 
to finding a particular match in the input stream, a rule would require 
thkt certain state variables have specified values before -the rule 
would b^ executed. A rule could also include the setting 6f given 
values for state variables in its Bxecution. A state variable may 
specify a very general state: for example, that the us^ is using' VER- 
BOSE mode; or it may indicate a very specific situation: for example. 
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/ 

that the interface has just sent the password in/ the login procedure to 
system X and is awaiting the response. Thus tne rules can be set up i 
to relate to, and "step through'* a sequence of very specific situations 
for various con^binations of general modes in effect. 

The rule must identify some par;fc of the input stream as meeting 
a particular criteriorf for match in order that the rule be' invoked — 
assuming of course that the state variables also ma^ch, as just described. 
That part of the rule that specifies the nature of ^he match may be 
called the. rule match , or simply match. Also, there is a pointer whach - ^ 
identifies that point (i.e, character) in the inpiTt stream at which thfe 
interface begins a scan of the stream to ascertain whether any rule match 
is satisfied — scanning going in the positive direction i.e., the di- 
rection in which characters have been added. A rule would include the 
specification of how to^ increment the pointer. 

Normally, after a rule is executed, a search is begun for the 
next matching rule in accordance with the rules of message priority 
as, for example, indicated above in Section 5.3.3 and rule ordering as 
discussed below in Section 5.3.6. However, it is conceivable that 
control should be otherwise directed after a givert rule; the .capability 
to provide this kind of direction should also be expressible in' the 
rule. FLg. 9 scheiratizes the kind of structure we have in mind. 

5.3.5 Message Formats, Timing and Segments 

Now we describe in greater detail the actual rule-matching and 
message-generation opei^ations required in the interface. First, we 
need to consider vthe format of the incoming messages. These messages 
can be decomposed into segments ; the most common and natural segment 
is aline; i.e., the character sirring ended by a new line or other line- 
ending character, like carriage return or line feed* For some systems, 
and in certain situations, only a partial line will be sent. Tliis 
will happen, typically, where ^ a system has a user prompt that does not 
end in an end-of-lin^ type character: as, for example, just a question 
mark on a line. 
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■ The basic mode of operation would then be to add a message seg- 
ment to the* input buffer when it is received and to i^erform rule matching 
on the^ incremented input stream which, in general, would represent a 
partial message . Of course, a completed message would be a special 
case of a partial message and particular' rule matches would attempt to 
^ identify end-of-message segments for special attention. The set of de- 
limiters specifying mes>sage segment boOndaries would be dynamically set 
by the rules. The size of these sets is quite small for most' common 
systems; it usually, ranges from just the end-online characters to that ' \ 
minimal set augmented by one or two punctuation characters like cues tioi^ 
mark or colon. 

A timiiYo function should be built ^into the message segment handling 
operation puch that characters coming in immediately after (i^.e., at 
a time interval no greater than that determined by the BAUD*rate) a non ^ 
end-of-line type character^^d^^^miter are appended to the message segment. 
This would avoid forcing the rules to try to handle partial lines where 
end-of-snjjrent delimiters are innocently included within regular lines 
wit-Iicut having an end-of-segment function. Conversely, if there^^ere 
,a seqmfiit not ending in one of the currently recognized delimiters, a 
timeout function would come into effect' to force the transmission of 
this (unexpecre Jly) short segment into the input stream, as well as 
setting a state variable to identify this condition. Two kinds of situ- 
ations could induce this kind of timeout: (1) the rules simply had not 
properly specified the current' delimiter set or (2) due to error con- 
ditions or the stochastic timing ^idiosyncrasies of the time-sharing 
mode of operation, the end of £ segment had been inordinately defayed. 
Note that a null segment would be a special case of this latter situ-, 
ation and would be identified by another particular state variable. 

If it were desired to base a rule. match on some features of a 
partial message that overran segment boundaries, this could be accom- 
plished by propeV setting of state variables, the "input stream pointer, 
and/or the rule^ match. Interrupt messages as well as timeouts should 
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set state variables so as to allow for all rules to be expressed in a 
uniform input/state description of context. 

5.3.6 Rule Matching Criteria, Transformations, and Ordering 

Rules may- be of certain rule t^es based on the kind of matching 
functions m effect for the rule match. For example, it may be 'desirabl 
to ignore upper-case/lower-case distinctions for alphabetic characters. 
Other rule types will be discussed below after a more "comprehensive 
discussion of the general matching criteria is accomplished. 

It is clear that. rule matches should be capable of specifying any 
given character or fixed chara<;ter string, whether these characters 
be alphabetic, punctuation, non-printing characters or, in general, 
any code. In addition it is advantageous to be able to have variable 
features of the; input stream be, specif ied- in the rule match. For ex- 
ample, it may be recognized that a character string (of indefinite 
length) that appears after a user FIND, command is to be taken as a (free 
vocabulary/) expression of a search topic and should be placed in a 
certain position in^he output message. A symbology is needed to re- 
present such a variable strincj for both the rule match and the rule mes- 
sage. 

^ Another kind of variable element would stand for s6me class of 

characters sav: end^of-line, alphabetic, non-alphabetic, numeric, 
command delimiter (e.g., semicolon or end-of-line) / etc. This kind 
of variable combined with the variable-length element would'provide 
the means to specify variable words and phrases of a given character; 
fo^ example, a number would be a variable-length string of numeric 
characters. 

It .is desirable to be able to specify that some identifiable 
elements of the input stream undergo some particular functional trans- 
formation, that is not (easily) expressible by the string manipulations 
of the rules themselves, before being (3eposite_d in a state variable or 
output message. For example, an arithmetic function may need to be 
performed on the number n, represented by a given string in the input ' — 
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which in turn may represent, say, the number of the first document to out- 
put — in order to properly translate to the appropriate command mes- 
*sage — e.g, "PRINT SKIP n-1" . The symbology for expressing this kind 

'Of transformation needs to be developed for incorporation into the model. 

Rules would be ordered and the search for a matching rule would 
proceed by that order. The first rule matched would be executed. There 
-would always be a default rule, in general, or in a particular context, 
so that unanticipated or default occurences could be handled. All vari- 
able states expressed by»a rule would have to be satisfied for the rule 
to match; a variable state not expressed by the rule would be ignored 
in the matching operation. Pule matches would generally be ordered from 
longest to shortest so that rules depending on more precise context 

.would take precedence over tho$e broader or default contexts. The 
specific ordering of r^jles in cases where ordering would not ever effect 
the actual choice of rule for any possible input streams and state vari- 
ables would depend on such factors as, whether the rules were intended 
primarily for exposition to a human analyst or for actual execution. 
In the former case, an ordering based on state variables might be pre- 
ferred; in the latter case, an ordering based on a compCfter sort order 
(e.g., alphabetic) might be preferred for efficiency of searching. 

The nature of ^the operations provided for in this model is 
schematized in Fig. 9. 

5.4 Retrieval Protocols in Cooperative Networks 

The description above of functions required in a networked inter- 
face for interactive retrieval systems, while reasonably comprehensive 
in coverage of the kinds of functions required, is limited in three 
respect€. First, as was f>ointed out in the beginning of Section 5.3, 
we have assumed independent Velirieval systems that could notbe changed. 
Second, we have tended to lump all the functions together in one un- 
differentiated mass withr *- regard to the different levels involved. 
Third, we have tended to ignore the structure of the network in which 
the interface would reside.' In this section we shall take a very 'pre- 
liminary view of what might result if we could go beyond these limita- 
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j In the first place, if networked systers coulc achieve that de- 
gree; of cooperation such that standardized corrj^unication protocols could 
be agreed upon, then many of the p'roblens of indefinite, unexpected, 
and ipnpredictarle ressages mentioned in Sections 5.2.2. and 5.2.3 could 



rcumvented or, at least, reduced in scope. ^ Thus, for example. 



mess^Lge completions, acknowledgements and system dropouts would all be 

:|nd|.ed in standard ways, 

In the second place r the network structure m which the interface 

r^sicfes has a strong impact cn how interface functions should be per- 

form^-o. In particular, we see in such ARPA^JET efforts as the RSEXK: 

1 2 ~ 1 4 38 

and the r^ational Software V/ords ' (see Section 1.2) the develop- 

ment of a distributed-computatxon approach to resource sharing basec' 
on comjTon protocols for mtercowmunicatinq among dispersed processes 
to handle a given application-. 

Thus, for example, it is suggested that any major application 
handled in the network, like interfacing to retrieval systems in a 
virtual mode, he implemented in several separated, but interconnected 
anS cooperating processes. There are at least two main reasons for 
resource sharing through this kind of structure: reliability and effi- 
ciency. Reliability is achieved by having separate processes each of 
which can individually handle the application. Thus, if one 'process 
is unavailable for any reason ~ failure in hardwa^^^of tware, or 
communications channels thie user can be routed to another process 
providing the same functions. Of coutse, the appropriate switching 
mechanisms must be available. Greater efficiency through load-sharing 
for example, can be achieved by routing users to less busy processes, 
rather than to .overloaded ones. , I 

A second aspect to emerging networked structures, where distri- ' 
buted processes are connected to and serve likev/ise distributed users 
at terminals, is the recognition of two kinds of processes involved; 
user processes and server processes . This distinction is in accordance 
with the actual nature of the network situation: users are attached to 
individual host co^uters and are, in general, required to makfe connection 
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to serving processes which reside in separate host corrputers. Thus it 
is quit.e natural, for each individual application, to 'have in each host 
computer a user process that takes all requests for that application 
and establishes in an appropriate and uniform way, connections to suitable 
serving processes in. the given and other cojpputers. Uniform access 
methods are key to effective network operations. 

The structure for a networked interface containing distributed 
user and server processes for retrieval is exemplified by the diagram 
in Fig. 10, where the overall interface process is still called "CONIT" . 
If we compare Fig. 10 with Fig. 1 we see that the module labeled "User - 
Interface" in the figure is included within the user process and the 
module labeled "Translation" is included within the server process. 
The function "Interface Management" in the first figure is distributed 
over both user and server processes in this revised picture. 

In this revised picture the communication between user and server^ 
is accomplished through agreed upon procedures and formats that may be 
termed the retrieval protocol . In particular, the user process trans- 
lates a user request into one in a common request protocol, (labeled * 
Command Protocol in Fig. 1) which the server process translates into 
the appropriate form for the retrieval program. Correspondingly, in 
the reverse direction, the- server process translates a response ^from 
a retrieval program to a common response protocol which is sent to the 
user process for conversion to a form suitable for presentation to 
the user. In the most general sense the protocol includes all the 
procedures by which the user and server processes communicate with each 
other as well as all the status information' for each user, includin^^SS^ 
all the various functions and function responses 'discus'sad in Section 4. 
We note that between user and server — i.e .'f^^jr intra interface — 
can conventionalize and standardize the protcols and thus avoid 
of the problems of networked communications as described in Sections 
b. 2 and 5.3. . ^ ' 

It is worthv/hile to consider the functions of the servei- process 
in 'greater detail. For non-cooperating systems of^t^e kind we are > 

% ■ ' . ■ . . 
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currently dealing with, the server pust communicate with the rest of" 
the network with the standard protocols while also handling the in- 
dividual non-standard features of each retrieval system. We may say 
that the server "encapsulates" the retrieval»^systers and makes th,em 
appear to the rest of the network as if they ^rformed standard functions 
according to conventional protocols. The "encapsulator" notion is im- 
plicit in Fig. 10 and made explicit- in Fig. ha. 

The encapsulation function itself may be sut^divided into a number 

of functions that successively carry and transforr the standard protocols 

J* 

into the retrieval systems and, then, the responses of the retrieval 
system backout to the network,* as shown in* Fig. IIB. First the en- 
capsulator rust" handle the establishment and maintenance of connections* 

to the rest af the network. Kext, the retrieval protocol must be in- 

•J * *■ — ^ 

V\ 

terpreted and^«^ther management (e.g., status keeping) functipns must be 
performed. Thirc^C^Kt^he intejrpreted px:otocol functions m^t be .translated 
into commands for the'^'^^^i eval system. Fourth, the translated commands 
^must be passed along to the retrieval systems, poss^ibly through non- 
network, non-standard communications channels, if the retrieval systems 
are so situated. Similarly, the retrieval system responses must pass 
successively through these functibna^i\rings back out t© the standard 
network interface mairrtained by the encapsulator . o;^ 
One advantage of the user/server process structure is that a new \' 
retrieval system that follows the common protocol can *be added to the 
network directly, i.e., no new translation modules are needed. In fa^t, a 
the third and fourth (shaded) rings in Fig. IIB cah be eliminated in 
standard network operations. For a retrieval system not following the 
protocol, at least a well-defined translation procedure is implicitly 
define;3^for the encapsulator. In addition, the intra interface protocols, 
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bedTng freed from a requirement for human intelligibility, can be concise 
and, therefore, more efficient for processing and communications. Also, 
having such separate communications protocols tends to isolate the sur- 
^ face languages and, therefore, make it easier to change those languages 
^ without making major modifications to the basic interface operations; 



5.4 




5.4 



.V 



One question for fut\5re research is how to characterize the 
stjructure .of the interfacre more finely in terms of function so that 
higher-2>^el semantic functions, e.g., commartd interpretation, are more 
^clearly separable from lower-level (syntactic) functions, e.g., character 
string handling. In any case, our current conclusions on the^ future 
role of communications and protocols in networked interfaces are given 
inflections 6.1 and 6.3 below. ' * 
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6. EVALUATION 

We have descjtribed the nature of the retrieval networking problem 
of coupling heterogeneous independent interactive systems; discussed 
gej^eral approaches 'to its solutior^ outlined specific techniques; 
and described an experimental system to ^id in analyzing the problem. 
In this section we evaluate the general prospects for resolving the 
problem and the several particular approaches we have considered. At 
this stage the evaluations are still tentative; more extensive experi- 
iTtentation and analysis will be needed to draw firm conclusions in many 
areas. 

6.1 Physical Interconnections 

^ Rapid developments currently in progress in the field of computer 
networking should soon' alleviate current problems in the physical inter- 
connection of interfaces and retrieval systems. Most the major opera- 
tional retrieval systems already are, or soon>7ill be, accessible vi^ 
, national and international computer networks. It should be possible to 

build 'the interface components on hosts that are part df, or can be 
♦ 

easily attachable to, t^iese networks. 

Especially valuable for retrieval networks are some of the features 
of the packet-switched networks of the ARPANET type. These networks 

r 

provide efficient multiplexing of communications channels for inter- 
active data that could otherwise use ^percent oi^ less of channel band- 
width on dedicated channels. Also, intercommunication between inter- ' 
face F^og^^n^s and retrieval systems are provided directly by network ' 
procedures and programs. In addition, recent studies have indicated 
that long-distance communications channel bandwidths and costs will be 
markedly reduced with satellite technology, making this component of 
networking even less of a potential barrier to success. 

6.2 Effectiveness of Interface Approach 

6.2.1 The Dimensions of Effectiveness 
' We are generally optimistic about the future possibilities of the 
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virtual-system interface approach and the various techniques we have con- 
sidered in 'implementing this approach. One must, however, recognize 

« 

the several dimensions along which effectiveness can be measured and 
the tradeoffs that must be weighed^ between effectiveness and cost. 

One dimension is the degree of " virtualness" provided by the 
interface, that is, -the extent to which the interface acts, as a common, 
virtual system, hiding all the heterogeneity and individuality of the 
different retrieval systems. A second dimension is the completeness 
with which the interface permits use of the various capabilities of 
the networked retrieval systems. A third dimension is the exactness of 
translation; that is, the degree to which the function called for in 
the common command language is fulfilled, and not overfulfilled, by 
the translated requests in the different rejtrieval -systems. 

Complementina the first thrfee dimensions is the dimension of 
the . compDshensiveness of the totality of retrieval functions permitted 
through the interface; this, in general, will be greater than what is 
obtained fror the networked retrieval systems since the interface it- 
self provides capabilities^ not available otherwise. A fifth dimension, 
closely related to' the fourth, recognizes the need f6r 'dynamic and inte- 
grated character to the solutions: the interface should be extensible 
as additions to capabilities and other changes ensue and it should be 
Integra table within the larger computer context of distributed net- 
worked computation, finally, the interface may be measured by its 
simplicity : how easy is Tt to use by the inexperiencfed user. 

^There are, clearly, tradeoffs that may need to be made among ' ' 
the various dimensions and between effectiveness, in getieral, and 'cost. 
For example, exactness of translation and coapleteness can be increased 
at the expense of^ virtualness; in the extrere, a Jsimple transparent mode 
requires practically no translation and provides acc^ss^to all the ^ 
functions of the different retrieval systems at the cost of complexity 
due to heterogeneity of access for the user. 

We believe the approach and techni^ques we have outline can lead 
to an interface sys^t^ that will score high in each pJ ^e six dimensional 
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measures listed above. We discuss below the possible effectiveness of 
several component techniques we have been considering: a common retrieval 
language, a Master Index and Thesaurus, and a common bibliographic dafta 
structure. 

6.2.2 The Common Rertriyeval Language ^ , 

The common retrieval language, .^^ch has been one of the main 
foci of interest in/this report, has import 'for all six dimensional 
measures.' We have/ discussed the ways in which we have tried t.o^pd^Qr- 
the lanquaae siniple, extensible, and integratable with other ^ufTctions. 
The set of r^J^^eval capabilities outlined in the common command language 
includes almost all the capabilities of all the retrieval systems we 
have been working with. In so doing, it includes, a number of capabili- 
ties which are not included, at least directly, in that system. Beyond 
that, there are a number of capabilities that are not included in any 
of the retrieval systems, either because they are fextensirms of^„e?fisting 
capabilities — like the extensive storing, sharing, and-retfsing of 
searches — or becaus^ they are capabilities peculiar to interface 
function — like keeping track of the status of, and connecting to, 
different systems. 

The comprehensive nature of the functions that one would like 
to obtain through th^ interface, together with the limited nature of 
Hhe capabiliti^^s available from existing retrieval systems, emphasizes 
a numbe^^-^^r complications that ve face in interface building. One 
problem, of ^course, is the cost of building\into the interface the 
features themselves or the connections to thim. Another problem is 
that of performing an exact translation of a Request in the common 
comjnand language into one or more commands in a given retrieval system. 
At a given^evel of sophistication of the interface the problem may be 
one of complexity or absolute impossibility . 

Thus, for example, as we have seen in Section 2, the current 
CONIT system cannot translate an arbitrary order of SH0V7 arguments 
to the DIALOG language. One could say that the full range of capabili*- 
ties was available to a user if the user was forced into the complexity 
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of using the fixed order^Jrequired by DIALOG. Of course, a slightly more 

sophisticated interface would handle the question of arbitrary order. 

Note, however, the default case for set name can ^be handled only if the 

interface keeps ^track of what the number for the curr^t set is, i.e., 

the tlrans^ation is dependent on session context. Neither of these 

examples is particularly difficult to handle, 'at least conceptually, 

r i 

and the mechanisms for handling them should likely be in any good 
operational interface. They do point out, howeve^, the idea that'' 
there is a series of successively more sophisticated techniques* required 
to hanc^le the problems encountered in achieving higher levels of inter- 
face perforir.ance along the several effectiveness dimensions. 

In a more' basic way, however, the translation may be (almost) 
impossible if' the retrieval system cannot perform a^ given function. ' 
*For example , a sort of the output by^ author last name may simply not 
be po^ible. The'qualifier "almost" is necessary since,, e.g., the inter- 
face — at considerable expense, at least c<Anpared to the costs of per- 
forming this and other operations within the retrieval systems — fcould 
Store the output, extract the author names, sort them, and then reorder 
th\e output. ^ ' 

Other functions which at least one of the systems W have reviwed 



cannot do, include: (1) handling of multi-line statements; (^) inter- 
rupting; (^) line delete; (4) separate mode; '(5) renait^g;- (6) 

^ ' /' ' ^/ 

antomatic stem search; (7) automatic corfunon-word exclusion searth 

*> 

(8) Boolean combir^ations in search statement; (9) nested Boolean state- 
mehts; (10) unlimited seardi terms frop a user-given stem search;- (11) 
word-order constrain£s primary search^ (12) Record search; (13) display 
and/or search of th^saurus-relatfed terms; C14) deleting selected sets; 
415) -reusing a previous search statemen€^ (16) intermixing search 
statements and combining sets; (17) SDI search; XTsl outputting of a 
selected* file ; (19) highlighting of matchi^<^ .elements; (20) displaying' 
counts of partial results; (21) saving seai:ch sets; (22) "keeping" 
selected documents in a special set; (23) saving output; and (24) re- 
viewing the previous dialog. It is not too severe, then, to say that 
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the set of functions that directlyi ahd exactly match among the several 
ma^or retrieval systems is- a small subset of the totality of functions. 
However, we believe — as we have* -discussed in part in this report, — 
that there are nethods, more d^^ess -difficult, for coming at least 
moderately close in translating the most b&sic and important- functions 
from a common language to the different retrieval systems. 

^-^.2.3 " The Master Index bttA Thesaurus 

The Ma^ster Index fihd Thesaurus (f^IT) , 'which was mentioned in 

Section 1.4 and whose specifications were described in detail, in our 

19 ' - - ^ 

'< previous report , appears to be a pov/erful t6ol ijx^rovi'Ging access 

individual, as well as a multiplicity of, data bases. It corftains 
esse'ntial infoi^^nation and ^interrela t^ionships necessary tc making in- 
telligent choices of. data bases, and search strategies. 

In particular, a user' couldjn^^ke -a -search request vjher? the 
search Jx>pic' is expressed'^iir ^natural English or in a cdntrolled vcx:a- 
bul^-tfy or in some combination of th^ two. Taking the word stems of the 
substantive v;ords-'in the user's request, the interface can use the in- 
formation in tVie MAIT — possibly with the aid of the user — to find 

^^--^ 16 ^ 

relevant index -terms. (We have di^j^tfssed in our Intrex work the 

clegree of relevance obtainat^r^ny these phrase decomposition and stem- 
ming techniques.) 'Tlae'''^ocun\ent counts associated with these terms pfQ 
vide sound information by which to 'base a selection of data bases in 
which to search as well as which inSex *tenns under which index elements 
to search on. Thus, the Master Index and Th^aurus provides the bas^s. 
for a successful nety/orlc^^upling using natu^alTRq^lish V/ords and phrases 
t as a common intermediate language as well as providing "grejtly ^enhanced 

* capabilities for access within rtto^t* existing systems. 

These capabilities come at a price: there Is a sizable storage , 
requirement and a 'major updating requirement. However, considerinq ^ 

' the larae potential advantages of" the MAIT, neither cost need b^ .thought 
of as a pj^ohibitive. Index and thesaurus informa^tion may ^be only 5 
percent of the total size of a large data base; thus, considering some 
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o^^lap'in terns, the MJ^IT for 20 data bases would ilkely be smaller 

than a single data base. Also, while updating "frofh multiple, sources 

would require a good-deal of coordination, it is possible that most 

of the advantages of the MAIT could be retained with infonr^ation that 

was several months or a year old. This is analogous to a profile for 

prospective SDI being developed on a retrospective data base. 

An indication that Master Index and Thesaur^is type concepts are 

now being recognized and incorporated into current Systems is thie recent 

'40 

development by Lockheed of its DIALIST merged term frequency indexes 
in microfiche. 

6.2.4 Common Bibliographic Data Structure 

Another consideration in the development of means for users to 
interact effectively with different, data bSses is th6 interrelation of - 
the diverse data elements and structures from those data bases. First, 
searching is done on one or more data elements: in order to translate 
a^search request in the common language into a request in a retrieval 
system the correct correspondence of data elements must be found. Simi- 
larly, user output requests require the specification of combinations 
of data elements. Finally, in order to combine retrieved docuirent sets 
from different data bases, we need to: (1) identify when document re- 
ferences from different systeirs refer to the same document; (2) establji^sh 
common reference forr.ats; and (3) create common ir\dex and catalog data 
structures. 

One part of the solution to these problems is the 'coiicept of 
a common bibliographic ddt^ structure mentioned in Section 1.4 with an 
illustrative example for J^art of such a 'structure shown in Fig. 3. We 
have described the development of this structure in our previous report. 

Our recent work has led u^ to question the relative value of our 
attempting further efforts in this area a^ this time. To take the last 
reason above first, ^e have not come close to the point of combining 
document sets from 'different data bases and creating mini-data-bases 
with catalog record^ from them, at least in an online mode./ Secondly, 

I 
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the comparison of data elements for searching may^^be best handled by 
the Master Index and Thesaurus, one of whose tasks is to distinguish 
data elements ujider which indexed.* Thirdly, while a corrmon bibliographic 
data structure is clearly important if refined distinctions among 
data elements are to be maintained, we have found that a rough trans- 
lation among data elements is often all that is possible or needed. For 
exaPiple, subtitles are not usually distinguishable from titles in most 
data bases and systems in which they are, -if anything, simply lumped 
m with titles. Therefore, we can not easily make use of a structure 
that is more detailed. At any rate, distinaulshing sub-titles from 
titles may not be very valuable and some systems, as we have seen, do 

not even allow separation of title from' several oth'er data elements. 

41-42 

v;e note, m any case, that efforts appear to be gaming 

headway to develop a common approach to bibliographic data e laments 
and to data structures in general. It may, then, be advisable in 
near-term interface work to await these developments while making use 
of coarse-level common data structures and translations. 
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6.2.5 Costs and Benefits 

Ip is too early to analyze precisely either the costs or the 
ben» fits of the interface approach. However, some order of magnitude 
estirrates can be made. The interface requires duplication of certain 
functions regularly performed by retrieval systems: the parsing o/ in- 
lut requests and the handling of dialog. Also, communications require- 
ments are roughly doubled in that the interface-to-retrieval-system 
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functions 
be new 



links have to be added to the terminal-to-computer Jinks ♦ Some 
like selection of and translation into, target systems — ^ would 
(although such functions are mirrored in the individual system functions 
of data base selection and common renaming) . On the otl^er hand/, the 
na^or component function of the actual storage and retrieval from very 
large data bases would .not be required within the interface, at leas^t 
for a rough translation! without a Master index and Thesaurus • Stimm'ing 
up, we give as a very rough estimate ,an additional cost i^or the computer- 
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syster comf^onents of approximately 20 percent for the simple interface 
over those same costs 'for direct access. 

The benefits ^corresponding to these costs ar^ (1) an increase in 
accessibility of perhaps' an order of magnitude in terins of the number 
of data bases and systems of practical availability and (2) a reduction 
of — and, in some cases, an elimination of — the need for a trained 
intermediary information specialist searches. 'This second benefit has 
a direct positive benefit in the direction of reducing total costs 
so that overall costs for interfaced access to retrieval systems^ could 
be the sare cr less than for direct access. This figure of 20 percent 
increased computer costs is partially supported by observations on 
costs of the current COKIT which, although not having all the functions 
of an operational interface, has been designed more for experimental 
expediency than efficiency and cost effectiveness. 

If we consider a more sophisticated interface with a large 
Master Index and Thesarus and extensive instructional capabilities, 
the incremental costs could go to the 50 to 100 percent range, or 
higher.' Hc^^ever, benefits then would include much improved retrieval 
capability and ahajity for the end user to 'make easy access to the 
data allowing many times more users to gain direct access. Vie would 
also^ expect the incremental cost of the interface to be reduced as it 
became better integrated with the target systems. Of couirse, this 
benefit relates [to the long-ran^e goal of more compatible retrieval 
systems. j \ 

6. 3 Logical Inteijconnections 

As important as how cost effective the interface can be is whether 
this approach is the appropriate one compared with alternatives, and ' 
how it fits into the developing scene of sharing of resources through 
networking with distributed computation. We have' not in the past year 
seen any reason to believe that the problem of heterogeneous retrieval 
systems will be resolved in th^ foreseeable future by any single system 
joecoming dom/nant nor by existing systems all agreeing to -follow a set 
of (ye t-to^-be- developed) common standards. 
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Ther^ have been soire indications of a trend toward agreements 
on certain aspects ^^'^^ of retrieval operations — like login procedures 
and data elerent definitions. Also, of more immediate importance, there 
is a continuing trend for each system to J'fill in the gaps" by incor- 
porating those features which other systems had and it had lacked. 
Counterbalancing and, perhaps, outweighing these trends are the exten- 
sions of these systems in new and different ways and the development 
of new. and different retrieval systems. 

Three other paths toward greater compatibility among systems can 
be stated. We have already mentioned — above in this section , and in 
Section 6.2.4 — the efforts toward development of a common bibliographic 
d^ta structure and common, compatible data structures, in general. These 

developments can be used by interfaces to aid in providing for greater 

1 

compatibility; they certainly would not, however, even when they come 
to fruition, obviate the need to overcome many other differertces or to ? 
develop networked structures. r' 

J A second attempted line of work has been in the area afe compati- 
bility^! among' computer programs ther^elves , It is the goal ofiithis 
development, 'either through the use of common or compatible programming 
languages, to make it easier to transfer programs from one system to 
anothei-. Interface work should certainly keep track of, and take ad- 
vantage of these develi^pments . Howevet, major developments along this 
line do not appear ^ikely to provide important aid for our problems 
soon; they certair^y will not, in themselves, resolve the many problems 
of networking heterogeneous retrieval systems, especially for existing 
systems which do not include them. 

The third line of progress, which may be the most important in- 
the near and intermediate term,/ is the development of high-level proto- 
cols by which different systems can communicate with each other by user 
and server processes in a sf4cific application area. As discussed in 
Sections 4 and 5/ these developments are closely related to pur common 
retrieval language development. Several consideration? arise in de- 
termining^ the nature of this relationship. 
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Perhaps the critical questions are how closely the individual 
systems differ from the protocol and how far the interface should go 
creating a fully virtual system that hides, or compensates for, the 
differences among systems and data bases by major functional capabilities 
within the interface. To the extent that there are important differences 
and that much virtualness is desired, we can expect the interface to be 
a ma]or component of the whole retrieval network. In this case the 
appropriate structure for networking may fce to separate out the large, 
costly functions into an interface which stands alone t- or has only 
one or two replications for reliability — between the various user 



le various 

1 * 1 

tetriefal 



processes and the server processes encapsulating the Retrieval systems. 

In such a case; the user and encapsulating prodesses mdght be 
much reduced ixi scojje *^in that many retrieval functions^ as su^h, would 
be handled separate 



the relations among 



y by the intermediate interface, in any case, 
a common retrieval language, a high-level retrieval 
protocol, a virtual ' retrieval system interface, And user and serve^ * 
processes for retrieval and other applications are clearly very important 
issues in future interface development. 

6.4 Areas Requiring Further V^ork 

We have discussed in some detail in^his report our approach 
to the problem of netv;orking heterogeneous retrieval systems and the 
likelihood of various techniques being usaful in the solution of this • 
problem. While v/e have established a number of Vvenues that seem* 
fruitful, much additional york is needed to evaluafe^ adequately the^ 
cost effectiveness of the individual techniques and the prospects for ^ 
their succesrful integration. Because there is such a range and d^pth 
of research needed, it is important to select what might -be most pro- 
fital^le for near-term effort. We especially want to point out areas 
within the field of information retrieval that might not othe;:visp 
receive adequate attention. ' ^ 

Our immediate plans call for the evaluation^ in some detail of the 
question of how effective a fairly simple and not-too-costly interface . 

127 , •. 
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(see Secjjticr. 6.2.5) would be in enhancirtg aecess to multiple systems an^ 
liata bases' for the }cind of potential user who is bqth most numerous 
and most in need of assis ta,nce : the /i*ne»perienced--e»4 u^^^. "Fairly 
simple and not-to<5-GOStly^' na^ be defined roughly as what could ulti- 
mately be implemented on a mincomputer class computer. The instructional 
facilities are clearly key in providing access for inexperienced users. 
The best way to perform' «this evaluation in our opinion, is through^^^^^^ 
actual use in an experimental interface. ^ ^ i 

SubsiHiary and longer-range s^tUdies, as suggested in the body 
of this report, are also very important. To 'reiterate and extend a few 
of 'these areas : ♦ 

(1) further exploration of the Master Index and Thesaurus 
cQn'cept, including automatic selectiqn of data bases 
and searches . . . / ^ 

(2) Further study of retrieval network software archi- 
tecture including protocols and loser/server programs, 

(3) Further analysis of cos t'/bene fits effectiveness/ ' 
expecially ^or the more advanced ' functions of the 

\ interface. 

(4) Continuing analysis of inter-computer and network 
communications possibilities . ^ 



/ 



(5) Extending study of hov; retrieval systems could be / 
mddified, or developed from scratch, so as to per- 
form better in a network environment. \ 

(6) Consideration of the question of whether tl^ere are 
actual advantages to having different retrieval 

^systems . 

(7) How is design affected by an operational^ many^user 
environment. ^ 

(8) To what extent can the interface development help 
, t^intj toWa'td retrieval standards? 

(^'Jv to integrate the retrieval ^function via net- 

working into the more general information transfer 
and general information processing realms. 
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(10) ^special problems will be faced in going from 

a research to an operational environment; e.g., 

(a) who would administer the interface? 

(b) ho^' would payments be handled? 

(c) what changes in existing system^ procedures 
would ipe* advisable? 



6 . 5 Conclusion^ 

Continued research on the networking of heterogeneous interactive 
information retrieval systems has lent further credence to the belief 
m the value of a virtual-system, computer interface as a means to 
achieve the networkin^g. In part, the evidence for this result^has cone 
from l|he development and initital testing, of an experimental interface 
callea CONIT, which contains the basis for a common command and response 
language and an initital instructional mode. CONIT enables a user to 
select one of four different retrieval systems to which CONIT auto- 
matically connects, and to perform many of the basic retrieval functions 
of the sys'tenv using the common language. 

Our research has suggested that a practical, operational inter- 
face might be developed which woulrl add perhaps 20 percent to the com- 
puter costs for online retrieval but relieve the need for a trained 
intermediary searcher. S'uch an^ interface might be most cost effective 
in the near future if it emphasized access to most, but not necessarily 
all, existing functions of several retrieval systems for the inexperienced 
end user. 

Progress has also been made in the analysis of the important 
components of retrieval networks, especially a command language, net- 
work structure, and requirements for ease of use. Fruitful areas for 
additional efforts have been outlined including the study of a niimber 
of research jissues that have been uncovered but not fully resolved in 
the work by us and others. These issues include (1) the extension of 
interface capabilities into a more fully virtual system by such poten- ' 
tially powerful techniques as a Master Index and Thesaurus and (2) the 
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the design of interface structures so that they fit in with, and enhance, 
the newly emerging networking software and harc^re technologies and 
other efforts toward compatibility and standardization in retrieval 
and other information processing areas. 
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APPEJf^DIX A 



SAMPLED USER/CONIT DIALOG 



X 

This appendix lists excerpts firom dialog between a user and CONIT 

lieh are intended to illustrate varioife facets of the interface situation. 

\ 

le excerpts reproduced from computer terminal printouts with some 
sduction in size. Annot;ations by the authors have been adde'd to help ^ 
reader understanding and are enclosed in boxes. Excerpts form a continous * 

oialog except where ellipses ( ) indicate some dialog has been taken out. 

Fach. al^^^rent session is so indicaj^ed. 

The first three pages cy^^cerpts (A2-A4) show a ^ssion with a 
very simple round of selectyf^ systems, data bases, performing searches, 
and getting output.^ Latt^ sessions (pages A5-A20) explore some of the 
noi^e involved considerations. 

The first page is additionally annotated to show the origin and 
processing of t'he messages. User commands are underlined. Messages 
originating from CONIT have a single" line alongside them in the margin. 
Messages originati-ng from a retrieval system that have been translated 
(at least in part) are indicated by a double line in thes^rgin. Messages 
v;ithout any markings originated in retrieval systems and were^ passed 
through by CONIT v/ith no translation. 
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con I t 

Welcome to COfJIT. For help on ho\/ to v^e COMIT youSay type '-help' 
followed by a carriage return; otherv;ise/ you may nov^^|ge any CCNIT 
command. ' *^ 

USErV: 
pick suny 



I Attachtnent successful. 



INDICATES SUCCESS IN ATTACHING TIP PORT 



SUMY/MELLIME: 
Connect i on conpl e ted • 



INDICATES PROPER INITIAL RESPONSE SEEN 



SS 1 i s nunber for your next search set 

I suny is connected successfully 
I You are nov; speaking CO*i IT 



fl USER:: 

find rad i a t i on 



INDICATES LOGIN COMPLETED 



aHESE MESSAGES.AND OTHERS, COULD BE IN 
BETTER, MORE VIRTUAL FORMAT AS DISCUSSEt) 
IN REPORT) 



SUflY/f1£DLlri£: . ' * * 

Your scarrh resulted in setl which contains this nany docu'^^nts: ( 268U) 

SS 2 is number for your next search set. 



'II USER:: 

sho\/ title' docsl-3 



It SUNY/MEDLIfiE: 
1 

T! - :STATISTICAL EVALUATIOD OF LIGHT PROTECTIOrf FACTORS: 

2 • * ' , ^ 

Tl • PROGNOSIS A'lC POST-THERAPEUTIC FpLliOW-UP OR BREAST CAMCtTRS BY 
THERrCGRAPHY. 



\ 



- 1 

Tl 



MICROWAVE THERf'OGRAPHY: A METHOD OF DETEtTIMG SUBSURFACE THERfAL 
PATTERNS. 



SS 2 is nuraber for your next search set. 



I LOCKHEED DIALOG SYSTEM PICKED 



I sen t 



INDICATES LOGIN SENT 



HOST IS OML IME 

M$fM<l RECONNECT @ 15:53:05 

' > ' ' \ , ' • • 

MEW FIL€ - DISSERTATION AB^. - SEE ?MEWS 

It USER:: ^ 
' ♦ pi ck da ta e r i c 
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File reset: ERIC FULL-TEXT ED & EJ DEC-7 
USER: : 

find radiation 



Your search resulted in set2 * USU R\DIATION (PROCESS OF EMERGY 



USER: : 

shov/ docsQshov; tf-tle docsl-3 



© CANCELS LINE 
TO THAT POINT 



Msg from IrDIALOG GOnC DOWN FOR THE DAY 

IN 5 MINUTES 
1 ~ 
EJ121G00 

Solar H.eated Homes: They're Here 



NOTE SPECIAL AND IA\PORTANT 
MESSAGE IN LOGIN 



EJ121508 

A Course in Nuclear Radiation for AM High School Students 



EJ121506 

Energy Al^'rnatives 



USER: : 
pick sdc 
sent 



SDC ORBIT SYSTEM PICKED 



YOU ARE ON LINE L8A . » . 

HELLO FROM SPC/ORBIT. ^ ^ 

YOU ARE NOW CONNECTED TO THE ORBIT DATABASE. 



SDC/ORBIT: 

* * ** 

TODAY ONLY: GEOREF AND APIPAT WILL NOT BE AVA I LABLE / SORRY 
F6R the INCOflVENIENCE. ^ 

♦ ♦ * * . /if 



NOTE SPECIAL MESSAGE 



SS 1 Is the number of your next SDC/ORBIT search set. 
USER: : 

pick data ntis , 



\ 



SOfi/ORBIT: 

THE TIf'E IS NOW 6 :56 P.fS"(EST), 01/16/^6 
YOU ARE NOW COfiNECTED TO THE NTIS DATABASE. 

SS 1 Is the nunb^of your next SDC/ORBIT search set< 

USER;: 

find radiation 
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SS 1 Is resuljting set contalntns this many docu'^cnts :( 21223 ) 
SS 2 IS the, number of your next SCC/ORBIT search set, 
USER:: 

show title docsl-3 



SDCyORBIT: 



Tl 

Tl 
Tl 



- Results of the Lyman alpha Veasurenents of the Satellite Plal 
Ergebn I sse de r Lynan-a Ipha f'essungen des Satelllten flat 

' f'.Qterials fata Retrieval at Estec ' 

- Angular r i s t r i bu t i ons cf Electrons of Enor.'^y Esub E Greater tFT^ 
0.06 f'ev in the J ovian f'agne tospho re ^ \ 



SS 2 is the number of your next SCC/ORBIT search set. 

USER:: 
pick n 1 m 
sent 

' LOGOM IM PROGRESS AT 18:59:30 ON JATOAHY 16, 1976 

BACK72 AT ML." A'lC SU'lY CCMTAINS 1972 CITATIO'iS O'iLY.*** 
TOTAL ACTIVE TSO USERS: 06 
READY • 



TSO LIME 07E 

ELHILL3 IS-yOT AVAILA^Li AT THIS Tlt^E. 
READY ^---^ • 



NOTE IMPORTANT MESSAGE 



USER: : 

pick suny 

Can't log off nlm 



CONIT DOES NOT YET RECOGNIZE UNAVAILABILITY 
MESSAGE AND GETS CONFUSED. ANALYST GOES 
INTO TRAtvJSPARENT MODE TO CARRY OUT TASK 
"MANUALLY" (V/ITHOUT TRANSLATION) 



USER:: J' 
sp host 

Transparent mode. All of your input \;i 1 1 now be sent directly to nlm v/Ithout 
Intorpretat Ion, except tho 'speak conit' comrnand which will cause COMIT to 
resume in terpret t nr, your requests. _ 

USER:^ 
logoff 

LOGGED OFF TSO AT 19:03:37 ON JANUARY 16, 1976+ 

DROPPED BY HOST SYSTEM 
PLEASE LOG Hi: A 
USER: : ' . ' 

sunyt* * ' 



PASSWORD: ben 
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NEW SESSION 



'j'au nju -f^ERr ir^L3 :t< COfllT 



SECOND PORT TRIED 
WHEN ONE UNAVAILABLE 



LIST STATUS 



INT. 



'('ciu RFE nou jz^K^y.irz-i' :ti ccjrm '-H^^GUPGi;: 



•=EDJ 



re : . ■ ' 

FIMC RLtTir^a»^""LtTHUr'^ 
F T. ID -I'-'U wTC f 

cariETiiE rci'r^ 



LIST COMMAND TRANSLATION T%#^BLE 
NOTES: (1) OLDER VERSION TjHAN IN 
APPENDIX C;(2) NO RESPONSE 
' TRANSLATrON TABLE AT TrtiS POINT 



DDCunrrrrj- th^ht hfe muu vciuf. cuFPcr^T ui/t. 

F'ERD'H 

Ppers-ur-E "c-J-fc-i- iFFnoiRTioM ;>-fect2-*. '>"nac:K- M.P. . l-a=Tat_i J.J. 
-ocuriE-tiT .:ti: LiT.HT-ir.T^ri-iTv uxjn-au u.E"ice uri^izitJC .ji-- xchieo 

• * - * 
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SHuu m rcH 



i. JCJCLi.i^.nT 



INDEXED EXPRESSIONS THAT 
CONTAIN RADH- OR EFFECT+ 
STEM 



'iH:fi-TITLE: 



• • f 



■ zr 



JHjiJ TITLE 
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, f .J, . . . 
:huui -It.*. 

* .'^nPUTUf^ JL. Co, itF ^TjU - T? »-.CT ^ ^ . 

,rFf: - . ' ^ ' ' • ' ' ^ 

rc'i-^'^ T - PEC ••jiijcp : 

^:L^iSSIrI':H~^:■M•-(iMM::EF^ " \ 

f I : rL-op--^L'jHrr-f D i r ii^i'rPE : 

Mr I r) 'H~ ^^C'I^iD 

Wnin HERDING 
itnin HERDi.jG 

' ' •Ei'-TEru rjnT^t=,IR:_ rf^PCriJhE '[aUDHrJE,sJ » ' ^ 

CUP PENT 'rPEr^OJ f >■ ^ ' 

»VJf ' ^E I L-LHr ICE • ' 0 ^ 

i^RRM ; I TICi4 TErPET.nTUF/i 



142 



A-8 



jur*« 'i: I u.LHNrc Pr-o::5f- Rnr»c . 

CCIKr.CIL or rt^JIOu^L LLL^-ii.i:r LUtn-p.r if, ^aiX PLHTEJ- UELi.-i 



C HlZh^ f IDCH 

ff 

J.J. 

mff 1 1. 1 01 1 -J' i-t in ! M" J I " r: I or 



nFriLinTIOM-T'ir'l" : 
r% E.r iv Fir r I L I nj i i 



III. I.iJ-T,^ r-.-hfriDL, ri.-^uir iCFUi 'l-ac, 'iccw. EtLiFT. ^ RncF.icPir^ r^ucLt-t-ir. 

I'DC. ' CT '-IL 

: OPPOPnTC-F^ILHTr' P : 

r'FDCeCDIMGJr or THe nriE'F ir,rHr^ PDUCF CCMi'CF.EMCE' 

I'lCETiriG-PLHCF!: 

:iEE:Tirit»-iTEj 

MCETIiMC-PELnrnp: 
PC 

:tOC UMCt IT -^'E Lf-iT I Of I- rrPE~L ode ; « 
.."tl 

L ITnTIOM-ELEKEriT-TVF'P- iIOjE: 
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r'Li:t. IC I'lT 1 0^ I- jRTL'-Or-i'-EL riTCZ-DriCUPE'f IT : 

I- cLllT cD- DOC iJMLf I f- 1 M»''P T f iJ ; 
111.. - !"JT. rrcHuai., i LHir-»^GD; Ii-l. ^ ' L'V^ ' 



OTHEP'-r I TRT lOr '-CLtMEt iT*: 0 IE : 
^i'O 

OTHER-i: I TjYt I Of l-ELEMEl IT':. : 

PELRTED-DOiruMEr IT-FOPn-rODE i 
10 

I r ISPEC-COr ITROL-r IUMBEP : 
3549^4 

I r l':.PFC -F'EC OP j-Ti'PE i 
PLfiC E-or-pJJ jl. I r r'ifiriM: 
riur-L'sEP-OF-Pr-iCES: 

::u' ^ 1177 

R'UBLISHEt^': 

luu. IrUT. TCCHMDL. 
PtRDV 

USEP: : . _ 
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pick medl i ne 
Attachment sj,ijccess f u 1 
Logon to host started 



NEW SfSSION 



shl??"?°cC„°t'i„':,' utltirjr""^-'''"' \ message m-^l^i^ 



. ..wx. . . ^ well 1 11^3 ; 

Type yes or y to continue, no or n to stop or dis to disconnect host 

TOTAL ACTIVE TSO USERS: kU 
READY 

TSO LIfiE CFA 

HELLO FROf/ ELHILL 3. 

YOU ARE NOV/ COriNECTED TO THE f'EDLINE FILE. 



MEDLINE: 

SS 1 is 'the number for your next MEDLIME search*^ s'et 
You are nov/ speaking in COfMT ^^^r^i, sec. 

USER:': 

show data > 
r.EDLIfiE: 

YOU /.:AY access the f^EPLINE, SOI LINE, CATLINE rESH vnr\RMlAPY 
A^'c^Efu^'^^^^^^^^ OLD rELl'OotA^U^lRY':^^^^^^^ 

SS 1 is the number for your^next rEDLINE search set. 
USER:: 

pick data sdi 1 ine 
MEDLINE: 

35 USERS LOGGEP If! PRESENTLY^. a' 
.YOU ARE NOW CONNECTEC TO THE SDILINE FlLEl 

SS'l'is the number for your next rEDLINE search set. 

USER:: . ' . 

show Index radiation 

'MEDLINE: . , . ^ » ' . . 

POSTINGS . TERM ' ^ 

' 1, RADIME (TU) ' ' ^ . 

k • , RADIATING (TV/) 

* . 2 RADIATIO^• (Ml!) ' * T . 

156 RADIATION (TW) , ' ^ 

23 RADIATION CHIMERA ^MH)^ ' 

To see more type »show rrore*. * . ^ 
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USER: : 
show more 



MEDLINE: 

POSTINGS TERM 

37 RADIATION DOSAGE (flH) 

.167 RADIATION EFFECTS (f'H) 

26 RADIATION CE\'ETICS (^'^!) 

20 ^ RADIATiON INJURIES (fIfO 

Ik RADIATION INJURIES, EX PER f f'ENTAL (f'H) 
To see more type 'shov/ more'. 



USER:: , 

find radiation* USER-GIVEN-STEM SEARCH 

4 : 



-MEDLINE: 

Your search resulted in setl which contains this many documents: (3U9) 

SS 2 is the nunber for your next ?'EDLlFiE search set. 

USER:: 

• • • 

find skin+ 
MEDLINE: 

Your search resulted in set2 which contains this many documents: (700) 

SS 3 is the number for your next MEDLINE search set. 

USER:: 

• • • % ' ^ 

find tissue* . , * 

MEDLINE: 

Your search resulted in set3 v/h i ch contains this many documents: (1057) 
SS k is the number for your next P'&pLltlE search set. 



USER:: 

combine set3 a#or set2 



# CANCELS PREVIOUS CHARACTER 



ERIC 



MEDIINE: ^ ^ 

Your search resulted in setU whfch corrta,I,ns this many documents: (1665) 

,SS 5 is 'the nunber for your next f'EDLIME search set. 

USER:: . . ^ ' . 

combine setl and set** 

MEDLINE: ' ' ' [ - ' ' , * , 

Your search resulted in seC5 v.;hich contains this many documents: (61) 

' " ' . ' * 

SS 6 is the number* for your next MEDLINE search set. 

USER:: 

rl38- 
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show title docsl-3 



MEDLIWE 



Tl - i<Stat Istical evaluation of light protection factors(t> 



2 

Tl 



3 

Tl 



Prognosis aVid pos t- the rapeut i c follov/-up of breast cancers by 
thermography. 



Microv/ave the rmog raph'y : a method of detecting subsurface thermal 
patterns. 



SS 6 is the number for your next M.EDLIN? search set, 
USER: : 

show abstract docsl-1 ^ 



MEDLINE: 



1 

AB - The protection! against erythema belongs to the cosmetic effects 
which lend thenselves to mathematical treatment. It is 
demonstrated W- on the basis of the optmal definitions given by 
El 1 inger and lichulze — that the calculation cf the mean value of 
the light-protection factor as hitherto in use^ docs not 
correspond td the real f r pauency-^d i s t r i 6u t i on . On the contrary 
there exists^ independent of the r/3di2ticn source hav i ng. sun 1 i ke 
characteristics and of the distance from the rc^diptor^ a 
b i na ry- 1 oga/- i thm i c standard distribution. V/ith reference tp the 
gradation principles of the human skin a t rens f ormnt i.on cf the 
pertinent differences of area is necessary first, i.e.^'a 
transformation responding to the Gaussian standard distribution 
principle. Tables a re .^re sen ted concerning the trans forma t i on and 
the practical evaluation of the light-protection faotor Q. By 
, aid of these tables a standardization of the factors' 0 ir^asured . 

by different authors has been attained as v/oll as a standardized 
' Stat istical-nathematical analysis. The investigation of the 
threshold dose producing erythema on the unprotected hur.on skin 
has revealed a strpe rpos i t i on of three f requenc y-d i s'^ r i b ut ion 
types (shov.'ing logarithmic distribution, tor) hav i n g /d I f f e ren t 
standard deviations. The results cf this entirely statistical 
classification pernlt^a ^afe forecast: the sunburn protection 
Inherent in the human skin is compounded of several contributing 
factors v/hich arc interconnected nu 1 t i p 1 i ca t i ve 1 y^ not 
additively. * - 

SS 6 is the number for your next MEDLIME search set* 

USER:: • , * * * 

St system 

USER:: * 

^open skinrad 
File has been opened. 



I SPECIAL TRANSLATION TABLE SET FOR TEST 



• • • 



OPEN FILE NAMED SKINRAD FOR SAVING 



ERLC 



USER: : 
save 

USER: : 



SAVE (=FILE>NEXT OUTPUT IN SAVED FILE 
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St med 



RESET TO REGULAR MEDLINE TRANSLATION TABLE 



USERt: 

sho\; title docsl-2 , ^ 

KEDLINE: 
1 

Tl - i<Statist Kca) evaluation of light protection factors<t> 
2 

Tl - Prosnosis and pos t- the rapeut i c follovz-up of b reas t cance rs by 
thermography. 

SS^6 is the number for your next f'EDLlME search set. 
USER:: 
pick data cancerline 

KEDLINE: ' , * 

27 USERS LOGGED IM PRESENTLY. 
YOU ARE riOl-HeeilMECTED TO THE C^^CERLIME FILE. 

SS 1 is the number for your next KEDMME search set. 

USER:: , 

• • • 

find skin and radiation 
MEDLIME: 

Your search resulted in set2 v;h i ch contains th!s many documents: ( 289 ) 
SS 3 is the nu'^ber for ycur next MEOLIME search set. ^ 
, USER: : 



shov; Ir- - 



MIXED CONIT AND ORBIT COMMAND 



MEDLINE: 

1 > ' 

AU - Sheleshko PV , , " ' 

Tl - CLirilCAL, MISTOLOGI CAL AND H I 5T0CHEM I CAL D I FFEREMT 1 AT lOM OF 

PRECArjCEROUS COMDITIOMS OF THE SKIN. 
SI - CARC/7»f/03302 ' ' . - 

SO - VGstn Dermatol Veneror; 10h2«*-28 197i* " 

SS 3 Is the number 'for your next MEDLINE search set. 

' USER: : ' ^ . 

St system 

USER.: : C: • ^ ^ 

shov/Qsave 

USER: : \ (i% 

St med 
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USER: : 
-sfrov/ ti tie docsl-3 

MEDLINE: 



1 

.Tl 



2 - 
Tl 

3 

ri 



CLINICAL, HISTOLOGICAL AMP I STOCHEM><fAL D I F FERENT I AT I ON OF 
PRECANCEROUS CONDITIOriS OF THE SKIN. 



r.lNIREVIEV;. REPAIR OF DNA IN MAflf-'AL I A>J CELi 



U'MUNOLOGIC ^BNORf'^LI TIES IM HEAP AND NECK CANCER, 
SS 3 is the nunber for your next fSs D L J NE'^?^r 



•arch set. 



USER: : 

St m'system, 

-USER: : 
view skinrad 
sk i n rad con ta ins 
' \ • ^ 

USER: : 

viev/ 1 ines 1-29 



2-9 1 ines . 



REVIEW SEARCHES IN 2. DATA BASES 
IN SAVED FILE 



flEDLlNE: 



Tl - (t<Statl stical evaluation of light protection fa<i^"ors<t> 



2 

T! 



Prognosis and pos t- the rapeu t i c follow-up of breast can 
thermography. 



SS 6 is the nunber for your next f!EDLINE search set, 
USER: 




MEDLIflE: 



y 



TI - CLINICAL, MISTOLOGICAL AND fn STOCHEfM CAL DIFFERENTIATION OF 
> PRECANCEROUS CONDITION? OF THE SKIN. 

2 ^ 

Tl 



MINIREVIEW. REPAIR OF DNA.^N MAh^AL I AN CELLS, 



3 

TI - IMrUNOLOGIC ABriORf'ALITIES IN HEAX> AND NECK CANCER. 

SS 3 is the number for your next MEDLINE search ser. 
USER': 



.USER:: 

show news v 

show is not a logal CON IT corrmand- 

Type 'explain comnands* for a list of conrnands. 



WRONG TRANSLATION 
TABLE SET # 



USER: J 
St med 
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rOES f'OT AND 
RECORD IS IM 



WILL MOT Pf^lMT 
ERROR AND V/ML 



USER;: 
show "nev/s 

•medliiie.'ie\/s\ data' 

1«*-JAN - in \VLi:iE PRlriT DERAILED 
ABSTRACTS. THE EXPLAIM Ufl IT 
BE CORRECTED. 

13 JAM - LriTIL FURTHER NOTICE, IM THE AVLIME FILE, TEXT 
WORD SEARCHING IS 'lOT AVAILABLE ON CORPORATE NAMES 
AND SERIES ThTLES. ^ ; 

♦ + ♦ + ♦ 

12 JAN - AVLINE \;i LL 3E AVAILABLE JAN 13 AT^NLM ONLY; AND MOT 
JAN 12 AS PREVIOUSLY \MMOUNCEr. 

12 JAN - SDILINE AT NLf ANT \J SUMY "01,' CONTAIVS 
* CITATIONS. fEDLlNE AT NL^l \MP TEPLINE \1 
CONTAINS- ir CITATI'0:;S FPOr JAN 197l» TNPU FED 1976 . 
BACK72, WAI LA3LE 'THRU OFFSEARCH \T NL»! AfJP SUNY, 
NOW HAS 1972 AND 1973 CITATIOf'S IN THE PATA 3ASE. 
THE 1975 f'ESH SHOULD rO\; CE USED WHEN SEARCHING AT 
'NLfl OR SUNY. 



FEB \y 
SU'IY NOW 



ERIC 



6 JAiN - THE EPILEPSY DATA BASE IS r^OW AVAILABLE TO ALL 

U.S. rEPIINE \ND TOXLINE USERS. ENTER "FILE £PILEPScY. . 
FOR SEARCHABLE ELEfEflTS ENTER "EXPLAIN UNIT R'^CORP. 
THE SEARCfUNG lEF\ULT IS TO \LL. FILE CONTAINS 16231 

, , RECORDS FROr' 19!»5 TO 1973 . 

IF YOU HAVE TROUBLE USING ON-LINE FILES AT NLfl OR SUNY, NOTIFY 
MS GRACE li f CCAPN, .' EDLARS fANAGEf'.ENT SECTIO!! (^01/1*96-6193). 
EVENINGS CALL THE NLf: COMPUTER ROff ( 3 01 /65 U-GU 22 ) , OR \ ' 



THE SUNY COfPUTEH ROOr ( 518/U7l»-j«2 1 ) » 



TSO LINE OFA 
, KEDLINE: ' » 

. SS 3 Is- the" number for your a ext flEDLJiJE search set. | 



USER:: 

show data all 
•medlhie.fi LES.OATA* 

DATA BASE TOTAL RECORDS 



♦BACKES 
BACK69 
BACK72 
♦CATLINE 

♦ CANCERLIflE 
♦CANCERPROJ 
♦CHErLINE 

♦ EPILEP.SY 
•JOURNAL AUTH 

KEDLINE (NLM)' 
MEDLINE (SUNY) 
MESH. VOC 
♦ NAflE AUTH 
SDILINE (NL.M) 
SDI'lHIE (SU'IY) 
♦TOXLINE. • 
CBAC 

TOXBIB 
I PA 

HEtP 

HA PAB/PESTAB 



5^5,1*63 
6i*§,3i*6 
Ui*9^5Gl 
155,277 
1*5,383 
5,517 
76,955 
16,|31 
1*^13 
U?6,937 
ff85,93L 
13,G2i* 



21,138 
21,13a 
29i*, 013 
11*6,805 
6i*>007 
21,088 

1*1*, 50*1* 
10,251 



ENTRY DATES 

651113-681111 
681117-711117 
71113Q-731116 



731130-760102 
731130-760105 



751210-760102 
75 12 10-760102 



15 J 
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^COVERAGE;/CURffrMCY 

Jam 66 - DEC 68 
JAM 65 - DEC 71 
JAN 72 - DEC 73 
1965 - ' 9 JAN 1976 
JAM 63 - DEC 71* 
1971* -'19:^5 



191*5 - 
_i97i* ' 

JAM '7U 
JAM 71* - 

1975 



1973 

- F£B 76 
FEB^ 76 



FEB 
FEB 

1971 
1971 
1971 

1971 
197r 



'76 



- riD-.PIC 75 

t PEC 75 
A SEPT 75 ' 

-\ SEPT 75 ' 

- JUNE 74 



y 
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* EMIC 
♦TOXBACK 
CBAC 
TOXBIB 

h; 

HAPAB^ 




HAYES 



7.5 

186,2t*8 

60,229 

7,221 
5,765 
10,0^*3 



1971 - 197U 



1965 
1966 
1970 
1972 
19^6 
13 68 



1970 
1970 



1970 
1970 
193tr^ 1970 



1) * = FILE'S AVAILABLE AT NLf 0\'LY. 

2) THE BACKFILES ARE AVAl LAB! E ONLY THRU OFFSFAPCH ' 

3) TOXBACK IS WAILABLE OHLY THRU OFFSEARCH \T MLm! 
TSO LINE OFA ^ * , ' . ' 

^:EDLI^jE: , ' . ' 



SS 3 is the number for your next MEDLIME search set 



USER: 



speak nonictrQ 
USER: : 

speak monitor 
From COrilT: 

You are r»ov/ speaking in flOMITOR node 
USER:: 

picj< data medline ' 

From con I T: ^ 

sent . • ' 

From COM I T to medl ine X ' ' 

"USEaS*'*'FILE rEDLIME 



MONITOR MODE 



0 



From medl ine : 
<tOOO(t023(t021 

From med 1 i ne : 

(t023<:02U201 

From medl ine : 

PROG: 
MEDLIfiE:' 
F rom medl i ne : 

1 

MISSING DOUBLE-QUOT^ /lARK. 
From medl ine: I 



bcTAL CODES OF FORMAT CHARACTERS 



RESPONSE FROM MEDLINE 



TRAlNSLATED RESPONSE FOR USER 



37 USERS LOGGED \:i PRESENTLY. 
37 USERS LOGGED \U PRESENTLY. 
F rom med 1 i ne : | ^ * 

YOU ARE MOW CONNECTBC TO THE rEDLINE FILE, 
YOU ARE riOV/ CONNECTEjC TO THE f'EDLINE FILE. 
From 'medl ipe : ^ 
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pick Ins 
sent 



NEW SESSION 

LOCKHEED DIALOG PICKED 



HOST IS o?:lime 

t<(MI$l LOGOM 7:56:15 



FILE 52 (f'ETADEX) C*:LP:£ 

FILE 35 (CISSERTATICMS) 0M4.|:JE 

USER: : 
sho\/ data 



1 -ERIC: EC, CJ 

5 -CflEr.lCAL \D5TrACT3 CO':C E'lG ATE S 

k -cx€;ept I c" M ("^MirPv!:'.' \3st. 

5 -3 I OS I 5 ^rrviE'.;s 

6 -::TI3 

7 --SOCIAL SCISCAP.CH 

8 -CGI PE'irix (CI ) 0 - \\h'/\nv 
10 -nAL/c\p. 11 -rsYCfi ^^s 

12 -IflSPEC-' .YSICS 

15 - rispEC-:LECTr.0MC3/cofruTCPS 

Ih -ISrEC 15 ->1GI/ i VFOF," 

16 -PTS Cii:;7CLECT. fKT. \uST. 

17 - PTS ..EEKLY CrA, L\ \, AMD FaS 

18 -PTS FTiS l'^ - PTS Cn 

20 -'PTS POf. :TAT 21 -PTS FOR. CTAT 

22 -EISYour search resulted in set 25 -C LA I f 'S-CHEri CAL 

21* -CLAir S-CE*' 

26 -FOu:iD\Tio:: ni rectory 

27 -FQL.'irAT I C'i CnAMTC P'OEX 

28 -OCEANIC \2S 29 -fvETECPVGEO \BS 
32 -fCTATEX 

Ik -SCiSEARCH 35 -C 1 SSCRTAT I OflS 
USER:: 

pick da ta nt i s 



USER: r 
* 



•FILE6 ^ ^ 

Even t : T i rr.e, Saa re hT i nc , Hc-^te , I'sr* r* , Tesc Pocs / F i I'e 
End: 7 : 1*9 : 25 , 015 . 2 1 , 01/ 19 / 7C , 0 108 , 0000, 0 000 , 0 1 
File reset: NT I S 196«*-1976 IS5 02 • ' 

USER:: 

show index skin 



lndexr;tern Typy I tens RT 

SKI LL5 C0*!VER5fO:i 

PROJECT 4^ ^ 21 

Jy - 1 

Kirr'ER -/- 19 

GKIMf.ERS i---. i^Q 

SKIfll INC--*- 11 

SKIfl -- 2231 

SKIM (\flATOr^Y) 28 

<;iflN r AMATOfY ) 2U 1 




^Kir- 



J 52 
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(BIOL) 

(STRUCTURAL rEr3£R)' 

A3S0RPT1CM 

ANALYS0R3 

CE'lCS 

CANCER 

C I SEASES 

EFFECT - 

FRICTION 



/E9 SKIM 

ElO SKIM 

Ell SKIN 

E12 SKIN 

E13 SKIN 

Elk SKIN 

E15 SKIN 

E16 5KIN 

E17 SKIN 

E18 SKIN FRICTION PRAG-'-' 

C19 SK1N FRICTION C\CES-- 

For more type 'sho\^ more' 

USER:: i 
findsin##kin 



8 
29 

S 

1 

1 

3 
57 
16 
567 

3 

1 



Your search resulted in setl 2231 ^KIN 



tSER: : 

find rodlai ion 



Your search resulted in set2 353C5 RACIATIOf 
USER:: 

combine setl and set2 

Your search resulted in set3 203 1*2 
USER: : 

show set3 title docsl-3 



LA-UR-75-1633 f)TIS Prices: RQ?>3 . 50/rF5 2 . 25 
; Meson Radiobiology and TheraT^/ 
Aug 75 8p 

2 

COO-236C-«4 NTIS Prices: PCC 3 . 50/f'F'<. 2 . 25 

Damage and Repair in Skin Following Exposure to ?.adioactive 
Particles. Pro,';ress Report for the Support Period Ending 31 July 1975 

19^5 8p 

>3-2U6' 283/6ST NT I S Prices: PC ^3 . 50/fF ^ 2 . 25 

Kethods for the Production of Interferon in Cultures of hunan 
Diploid Ce lis 

See also PB-233 G53.. 

20 Feb 75 21p 



USER:: 

nf skinrad 

File has been opened. 

^S^R:: 

^iev; skinrad 
skinrad contains 

USER: : 
1 ines 1-9 



REOPEN FILE FROM PREVIOUS SESSION 



29 lines 

REVIEW PART OF FILE (MEDLINE SDIUNE SEARcfnTI' 



MEDLINE: 



1 53 
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1 

Tl 



<i<Statist ical eva-luotion of light protection factDrs<i> 



TI - Prognosis and pos t- the rapeu t i c follow-up of breas t cance rs by 



USER: : 
file 

USER: : 

shov. ti ti^'^'^sot5 title docs2-2 



SAVE ONE TITLE FROM CURRENT SEARCH 



COO-23C6-14 fills Prices: PCS 5 . 5 2 . 25 * 

Cone^e and P epair in SLin Following Exposure to Radlorctive 
Particles, f^ror.ress Report for the Support Period Ending 51 July 1975 

19 7:> 8p, 

USER:: 

pick data 54 
.FILE 514. 

Event: T i -e , Sea rchl i -e , Tn t e , Lse r ^ , To sc r , Tecs , F i le 

End: 8 : 0*4 : 5 5 , 01 5 . 2 5 , 0 1/ 1 3/ 7G , 01 08 , 0002 , 000 8 , 0 6 . ^ 

File reset: SCISEATCH 7i4-75 i:Ki48 

LSER:: 

find radiation and S'kin 

Your search resulted in set^* 27 RAD I ATI 0>I( F ) SK I N 

USER:: . - ' . 

shov; tit**<i^set5 title docsa-5 



915065 (***not online***) 



915828 C***not online***)' 



915158 (***not online***) 



ERROR DUE TO ASKING 
FOR SET NOT AVAILABLE 
FOR CURRENT DATA BASE 



USER: : 

pick data physics 
.FrLE12 

Event: T i ne , Sea rchT i ne , Co te , Use r I , Pe sc r, Pocs , F i le 
End: 8:07:00,002.51,01/19/76,0108,0 002, 0000,514 
File reset: i MS PEC- PilYS I CS 70-75 I SS 25 

USER:: 

find radiation and skin 



ERLC 



Your search resulted In setS 
USER:: 



\^ '^ADI ATIOV(F)SKIN 



ioi 



-146- 



• A-20. 



show sets title docsl-3 » • ' 

1 ' t ^ 

816773 A7?7U583 

AM IMTER.0CVPARI30M OF RAD I OPf lARP A'CEUT I CAL KI^^»EY KT^ETICS \'l THE 
KGUSe ' \ '* 

80U602 \7567ii79 ' - 

THE EFFECT QF lOmZIMC P.ADIATIO?; ON PROTEIN rETABOLlSf^ \U STORED -RAT 
S K I ^J ' , , 

3 . - . ^ 

801027 \7563291 ' . 

HEAT BALA-:CC V\D TMERfAL RESISTANCES OF SHEEP:S FLEECE 



USER:: 
file 

USER:: 

show sets tide docs2-3 



SAVE TWO TITLES FROM 
PHYSICS ABSTRA CT SEARCH 

\ 



2 

80U'602 MSSlhJS' 

TME EFFECT Of I OfM Z I NG RADIATION ON PROTEIN rETABOLISr IN STORED RAT 
SKIN 

3 ^ 

801027 A75C3291. ' • ' 

KEAT BALAfiCE A\'D THERf'AL RESISTANCES OF SHEEP:S FLEECE 

USER:: 

viev; skinrad 

skinrod contains U7 lines 



USER:-: 

1 ines 30-U7 



REVIEW LAST 2 SEARCHES IN NTIS 
"AND PHYSICS ABSTRACTS DATA BASES 



2 • , . ' • • / ^ 

COO-2365-U NTIS'Prlces: PC$ 3 . S 1 2 . 2S 

Damage and Repair^ in Skin Following ^Fxposuro to^ Radloijctlve 
Particles. Progres^s 'Report for the Support; Perrod Endine 31 July 1975 

197S 8p , , ^ , 

2 ' . 

80U602 A7S67U79 

THE EFFECT OF IONIZING RADIATION ON PROTEIN METABOLIS?-* IN STORED RAT ' 
S K hN 

* 

801027 A7SC'3291 ' ' ' 

HEAT BALANCE AND THERMAL RESISTAfJCES OF SHEEPiS FLEECE- 
USER: : ^ V * ' 
find skin* 



E-1 
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APPENDIX B 



CONIT INSTRUCTIONAL MESSAGES 

\ ' '^^is appendix lists the various instructional messages a user can 
^request -currently in the experimental CONIT system. The initial "welcome 
message ^ user s-ees when first entering CONIT is shown firsts to provide 
son^e context. ^Following that is listed the response to various instruc- 
'tion requestihg, commands.' These commands include the 'help ' 'commanc^ and 
the 'explain* command. As explained in Section 2.1, the * explain' command 
name (abbreviation: 'e') is followed ±>y the name of some concept the -user 
wishes the- com T system to explain. - ^\ 

The listings are copied directly from a computer terminal print- 
out so as to give the format exacJJL^^as a user would see it, except that 
size has been reduced by 20 percent. Another exception is that the user 
commands have'been underlined for clarity. The conclusion of a CONIT 
response is indicated by the user prompt (,USER::). 

It' is to be pointed out that these* messages represent our 'first 
attempt at* aa in^tructio/^al 'dialog for COKIT. Experiment >^nd Analysis 
have suggested general principles ahd particular modifications we would , 
propose, as indicated in the body of this report. 



* i 
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i;elcofre to COM IT. For help on lio;/ to use COM I T you nay type 'help* 
follo'./ed by a carriase return; oti.orwise, you may nov/ type any CO'ilT co-anand 

USER:: 
he 1 p 

In order to p;et information about how to use CO\'IT you type the 
cormanc;! name ^explain' (oV just e); followed by the narr^.e of- th(/concept 
you want explained followed by o carria-e return. For example if you type: 
expla in start 

you \/ill set an explanation of how to start to use COMIT. If you type: . 
e concepts 

You v/ill fjet t 1 i.st of the concepts you can have explained, 

USER:: 
e start 

EXPLAMATIOM OF CETTIMG STARTlD 
To sdt started you pick a retrieval system to search in -by 
command name *pick' follov/ed by tfie system you want. e»c» If 

pick med line 
you \;i 1 1 f,e t connected to the r.EDLIflE system, 
are sdc, lms( Lockheed)^ and intrex. 
After connecting to a retrieval system you 
are available by typing 'show data*. 



typing, the 
you type: 



mny 



Other systems you ray pick 
find out \;hnt data bases(fi]es) 



USER: : 

e concepts 

LXPLAHATIOfl OF COriCEPTS 
To have a concept explained type 
Soire concepts you can have explained 



COilCEPT 
con T t 
start 
conrnands 
conve r se 



'exp lain* 
a re : 



follow'^d by a co-^cept namo 



COMCEPT- 

Short introduction to COMIT system. 
Hov/ to start running CONIT 
List of COii I T con-ma nds 

How user and CO!lIT converse: the mechanics of the 
interacting d i a«l o*';: . 
Explanations are also available for the individual commands. 



ERIC 



;ER: : 
don I 



Explanation of COMIT 
COMIT is a system tlia't connects you to different information 
retrieval systems and allo\;s you to select oriy databooe of any of these 
systems to search (find documents). You can use a common (COfllT) language 
for giving com.Tands or use the language of the system you are searching in. 

bSERr: 

e converse 

EXPLAMATIOM OF HOV; TO COiWVERSE \/l Til CO:!IT 
You tplk \/ith COMIT by skiving it cop-riands . Each cor/nand consists of 
coinmand nar:e \/hich may be followed by one or n^ore addi,tirnal words to i 
the meaning of the comr-ands clear. (Type "explain comnands * fo'- details.) 
To signal the computer that you htivo completed your, cormand you f'UST 
strike the ca r r i age ' re tu rn kev; tlie comptiter will just wait until you do. 



a 

ake 



coriiT \i\ 1 1 

i ts message i s 
COr;iT will pri 



respond to 



comp 1 ete 
nt the * 



and 
user 



your command 
t!)at it is 
cue* : USfR: 



com)and 



You cannot give a 
connected to CO'HT directly thru 
interrupt CO:.' IT in its processing 
CREAK key after which COMIT \;i 1 1 
For other details^ like ho\. to 
^ explain converse more 

USER: : 



you 

with some message. To sit^nal that 
again waiting for your command 
: (just :: in torse mode). 



unti 1 yon g^ t the USr.R: : cue 'out^ 



ULTICS (not thru Ar?»\MET) 
of i ts 1 as K command by typ ing 
/Jve you a USnR:: cue. 
s t r i ng compMnds tb^^e the r^ type 



i f you c re 

you car(" 



the' 



157 
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G comands 

tXPLAflATIO\' 
The fol lo\;inf; 
Type 'c:jplain X' 

flAKE 
expla In 



OF 
i s 



pi ck 
find 
shovy 
conb i ne 
speak 

ADBREV* 

USER:: 
e p i c !s 



ABDREV- 
e 
P 



COf-'fAMDS 

0 list of CONIT coi-.Tiands 
•here X is cofrrrand namC/ ^ 
SHOaT e;<planatiom 

Explain COMIT concepts. 
Pick 0 retrieval system and database 
Sea^rcli database to find docu-nents. 
Show Information cn documents^ data bascs^ 
Corrb ine se-ts of re tr ieved documen ts •« 
Chanr,q cor^r^and la/iguage or language rrcde . 



or fur the cxp 1 ana t ion . 



to scarth, 



etc, 



abbreviated form of comcnd, 



ick, systems and data b^ses 
vhpre X is the narr.e of the 



to search 
system; e 



EXPLAfiATICri OF PICK COMMAND 
Tfie PICK coRTnand is used to p 
To pick a system type 'pic!; X*/ 
pick ne d 1 i n (J 
\ cet you connected to the. MEDLINE 
are sdc^ 1ms (lockheed) and intrcx. 

To pick a data base type 'pick data X' 
pick data nt is 

set the f^TIS data base up. as the current one you can search (if it 
!S available). Type.'sho\/ data' for list of dato>bases thojt should be - 
currently available from the currently connected system, 

USER:: . ' 

e f i nd 



system. Other systems yx}u m;Dy pf*i cK 
v;here X is data base name; c 



•EXPLANATION OF FIND COMMANQ , 
The FlflO comand is used to search for docu^eots indexed under, 
a particular term. Type 'find X' v^here X is the tern ycu are searching for 
For ex amp 1 e, * , - . . 

find t ranspora t ion . \ * 

find radiation effects 
, find energy conservation - , ^ 

If you \/ant to knov.' \/hat are alphabetically 
are posted type 'shov/ index X'.. 

For further information on ho\/ to make particular 
f i ndmore ' . ' 



nearby terns under v.hich 
searchc^^v type 



'ex 



docunen ts 
f)]a in 



ERLC 



focind 



,USCR:: . ' 

e shov/ ' * . . 

r.xpLANATio;: or snow command • ' ' 

The show corinr.nd r, ives information about dbcunonts that 
in searching/ .about d^ta bases^ about index terms to scarcl) 
To have CONIT show ,s tanda rd c i ta t jon M nf ormn t i on* an. scpiq of 
docunen ts you li^-ive found just type 'sh'ov/ ''; 9;bu may also bo 

show set3 trtle do^sl-^* 
\/ill cause the titles of the first U documents of.s6t3 to-be sho n t6 
For/nore detail^ on hc\/' to set docu/^'cnt informatiqn type .'expla i'P, sh^^v; doc^ ' 
-L/.anples of other information th<it' tdn -be obtained arc c;iv6n below: 

COtrXlD „ . ^ BRIEF fl^CPLANAT'lO?! ' ' ■ ■ . • " ' ' ^ " 

sho\/ tiata / Lists data bases CLi/rcntly oyaijcible * 

slio\/ systems Lists systems currently available^ * «^ • 

show index X * ^' Lists lindex terns oj plrabo t i ca.ll y ncaf X" 
sho\/ ne\/s Gives" ne\?s .fron- connected systejn ♦ . • * 

For more details type 'explain s!i'o\/ .da ta \ e to. 



'have been 
roy "etc . , 
the last set .of 
mere speci f iq: 



you. . 



USER: : 
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CXPLAIIATlOi: Cr COrCPIE COffANP 
1 [ic C0>:D!::L conTiond J 1 1 o^.'G you to ro!:o Ccnloan co^.'m n n t i ons of the sots .\ 
of doCMPH^ntb yoy l.cwc p r i o v i oi.'S I y found frc'i soarchinf^ your currently 
connccteJ (Jotri brjso; for exarn^l^^/ 

combine sct2 and sot5 
will ndkc a nov; sot \;I.ich contains only documents \l»ich am in both set 2 
and sets, oinilarly, , ' 

corpbine sct2 or sctS 
nakcs a no\.* set \.' i th a 1 1 docu. ^on ts frcn eitfior sct2 or sotS. Alsn, 

coinbino sct2 and not^setS *» • ' 

\;iil n'oke o ncv.' sot v/fiich co'ntcTins docur^onts in sot2 but not in sctS. 

USER;; ' \ ^ . ' ' 

e s0Gak ' ^ - V 

EXPLACATIOM OF SPEAK COfr\MD 
The speal; commond allov/s you to chan,'^e tlio cofrmand Ifinr.yar^e you are 
usins to speak to the currently connected 'system. Initially^ the * 
COniT lon^ua.TO is set-up, '.'lien you are connected to sonc hos t' Gys teoi 
you may speak to it in tfie co-^ron COMIT 1 oncua^e or in the host lan^ua^e. 
To speak in the host language type: * 

speak hos t " 
When you are sf>eaking in host lan^uac^ nc regular CO'UT corrrands \/i 1 1 be . 
reco<inIzcd except one: • ^ • ^ 

spea k con i t • ' . 

•.;!iich resets the lan^uai^e to COfllT. * ' V . 

U'iien 'speak i ns in the C0:1IT lancuar;e ycu v/ill get explanatory rassa^es 
from COiilT"^ After, you become fanii li^r v/J tfi COM IT you n\"iy \.'ant to have * " 
thesQ instruction mes^oscs shortened. You request this by typing 

speak terse^ * - ■ 
To resune norq lenr.tlW explanations type ' - ' * 

speak verbose , . . * 

US^R:: . ' ^ 

cxp<il in sunynev/s ^ * 
expalin' is not* a^'lei^al COtI I T cornandT? . ' • ' ' 

Type 'expjain commands* for a 1 T'st of commands, 

US%R:: " ^ , 

explain sunynev/s ' • ' . ^ ' 

< Tews i s not av^ i labld from the SUilY/j'EOL TIE system; to get news, 

about all the fHlDLINE ^ystems, including SU'IY, 'pick modlino' and ■ '-shov/, nev/s ' 

USER : : ' . ' . ' , ' 



e xplain n ^v; s • ^ 
COIilT canftot yet,exp^pin news 
Type explain concept/s * for a list of concepts Cdnit'can nov/ explain. 

USER;': • '. ' , . 
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APPENDIX C 

/ • • 

CONIT TRANSLATION TABLES 
t 

This appendix lists the five p^irs of translation tables regularly 
used' in the CONIT system. Tab 1^^ are listed for systems in this order: 

1. NLM- MEDLINE (tag: med) ' - 

i- 2. Lixrkheed DIALOG (tag-:Jmsi 

% >'i.\3. Systfems Development Corporation ORBIT (tag:sdc) 

: 4.. M.I^T. Intrex (tag: intrexr) 

. 5. SUNY IviEDLINE (tag:suny) 

For each system first. thfe command translation table (see Section 2.4) 
ana then the response translation table (see Section 2.3) is given. 
The tables are reproduced from computer listings. The commands set_table 
(ahbre viated: stj and list^table (abbreviated: It) are' use'd to make the 
able operative and t\}en to list it, respectively (see Section 2.5.1). 
.he tables themselves have been boxed in and labeled for ease of viewing 
J ^his report.^ Note that each entry starts at the le'ft hand marg^in-and 
' mis v;ith the asterisk (*) — spaces are' important . 'The input (left- ' 
hu.id or argument) side of each entry is separated from the output (right- 
^rod cr translation or function) side by the equals (=) sign. 



16 J 
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NLM MEDLINE COMMAND TRANSLATION TABLE 



yes=YCS* 
tohost=* 
ti tle = TI ,* ' 

shovt sys tems = e shpv; . sy s tor^s * 

sh.ow nov;s = "^"NF.W5* 

show noro = ciown 5* 

show index = ''!rBR^. ' ^ 

show datci an=""ri LES* 

sho\/ dota = *'FI LrS7* 

show = "PF<l r:T* . 

pick da.ta = "LSrRS^'''FI LE* 

of f 1 ino = OFF-l lf!E* 

l3 an = l.s a1 1* 

lO)^oul = '*ST0P»'*^^- . ' 

find ciuthor = "Fr!r* 

find = "FnL: ALL* 

GO'CSl- = * 

combine spt=* 
.j6st rac t = ALi, * 

sf)cw systo:Vis= sh.ow, sys tehs* 
s!iov/ neus= show.nev/s* 
shov; indcx= show, rndex* 
show (in>cs= s!"io\/ , docs * , 
show diita= shov/.cl^ta* 
sl«ov.;= show** ' 

, sct= SSi* 
or. sot= OR' * . • , 
find nTore= f i ncJ . more* 
f i rKl= find* 

converse r»jore= converse ,nrro* 
and sc t= AMR * ' 
and not set= AMP *10T * 
' i}U= *C ETA I LEO* 



..USER:: ^ ■ • 

S(i t_tab 1 e out nied ^ / 

•USER: : ' " ' ' • . 

list_l:oule out tsjLM MEDLINE RESPONSE TRANSLATION TABLE 



UP H OR LOW'l rj?=To soe v:ore typo 'shov; more'.* 
■H'=CO'l I T* [argument HERE IS USER ID; BLOCKED AND 
SS (=Your snarch-.rosul tod in set* TRANSLATED FOR SECURITY] 
PROG:=;iECLIfiE:* ' - ' • ' 

MSSING bOUnLE-'UOTE rARK.=* 

) PSTG (= whicti contains this many docunnnts: (* . 
/C?= is tf:o nunbor for -your next '!F.ri I'.'F search- set.* 



USER: : 
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/ 



list ta'L 1 o 



DIALOG COMAAAND TRANSLATION TABLE 



tohcs t = * 
si o\/ sn t = 



t* 



.slio\; offline set = r5rint* 
bho\< cf f 1 i no = o r i p 1 1* 
s\\o\: nov.s= ?nev/s * 
oj»o\/ '■•oro = 0* 
sl>o\.' index ju tl'.or = oau = * 
show i fTdox=cxpand* 
liiiox: ^'a ta = ?f i les* 
3:iov;=Tl* 

pick da ta = . f i 1 0 * 
' 1 s a 1 1 = 1 s' a 1 1 * 
fivi cmthor = sou = * 
f i n d = b * 

jo/ib i nc _ st^ t = c* 
+ = ?* 

Litle=/C* \ 
. psyclidb=ll* 

;)hys i cs=^l 2* ' 
-€:rsot = +^'. 

or =0 Irn^or* 

n t i,s =C* I 

( 1 eccofnp 
docs=/ * 
c.or'pende|< = o * 
c i ta t i on =/ 2* 
::l,oroab= 31* 
i n = 1,0*1 • 
and set=j** 
find not so t = 
and =(F)* 
al 1 =/b* ^ 
abs t rac i = / U * 



USER: 



ERIC 
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St out 1ms 
USER: : 

list tab! o out 



.DIALOG RESPONSE TRANSLATION TAgLE 



type in LC^iCFF as your last conmand,=You n re spoalinp; in CO^'IT,* 

sure proper account^n^ of your Runtine,=* 

a ? fron tlje compu te r= the L'SER:: cue frcn^ fO^MT.* 



Type in LOGOFF as your last connand,=* — 
Tol; (Ulb)i+03-i*275 = Lockhoe:i PIALOG* 
PI ease call (^+15) k^* 

LOGOFF ut = ni \LOn .soss ion terminated at* • ' . 

[ lALOC conpiand = CC'!l T connand* 
03-^+275 for (juestions or problems^*, 
*** I f'PORTAMT ... To in = * 
just prior to hanp,ing-up' ti>a, phone = * 
IT= docurrients in set for tern * 
? f= USER: : prorrpt f * 

0 =:no documents found: try 'show index ycurtern'* 
T= ^ T*'. 

-mo re- = For r^orc typo 'shov/ more'* 
=Your search resulted in sot* 



USER: 
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St sJc 



USER: : 



1 1 



ORBIT 



COMMAND TRANSLATION TABLE 



tohost=* 
\ t i tle = TI , * 

show news = ":lEw'S* 
i,l,ow i ndex = "tl3R* 
show (inta al l="r.XPLAI'l 
sf'iow i!ata='"FILES?* 
sl,ow="PRI 'IT* , 
pick data="TirE""FILE* 
off 1 ine = OFF-LI'IE* 
Is all=ls oil* 
find author = "FI^ID* 
find = "FI!!n ML*' 
aocsl-=* 
combine set=* 
abstract = A'J, * 
+ = : * 
set= 5S * 
or set= OR * 
pnd set= MW * 
and not 5et= AfT .'lOT ' 
al 1= FLLL* 



SCM^C* 

I 



USER:: 

St out sdc 

USER:: ^ 
1 t out 



'J 



ORBIT RESPONSE TRANSLATION TABLE 



mOG:=SCC/ORBIT: * 

/iP (OPEiJ )=Cannect i on completed.* 
MSSIfiC DOU'JLE-nUOTE* f ARK.=-.*' 

/C? = is the number of your next SDC/ ORB IT .sea rch se.t.* 
U^ER:: , ' ' ' 



ERIC 



16i 
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«> 


so citable in t rex 

* 




1 ^ c n • • 




1 i st_taole 




mi 


COMMAND TRANSLATION TABLE 


sho*.;=ou tpu t * 

or sotfor s* 

finu LltlG=title* 

find ou t!^or = au tlior * 

find=subject* 

con b i ne se t = s ^ 

and sot=and s* , 

and not sot=anJ not s* 





LSER: :"" 



sct_tdble out In t rex 
USER:: 

1 i statable out' 

1 ' INTREX RESPONSE TRANSLATION TABLE 



yoi^r request TITLE = your request FlflT TH"LE* 
your request SUBJFCT = your request Firir* 
■yoar re^quest Ai;TMOR=your roqurst FIMf^ AUTMOP* 
named s=nofTiecl sot* 
CLfrrcnt 1 i s t = c u r ren t " se t * 



USER: 



A 

16J 
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St suny 




SUNY MEDLINE COMMAND TRANSLATION TABLE < 



Li tle = TI ; * 
stio\. nev/s=cxplnin sunynovs* 
slinv; }nJex = ":]3R* 
slio\/ Jatd al 1 ="F I LES* 
sho\/ c.ata = "F I LEG?* 
show="PrJ'lT* 
pick <Jdtci = "L3Er>S""ri LE* 
cff 1 ino = GFF-L I'.'E* 

lSc3ll=lSdll* 

find >Tijthnr = "F 1 !."C* 

find="Fi;;r all* , 

docsX- = * 
combine sef=* 
abs t rcict = AB, * 



set= 53 * 

or so t= 0F> * 

<jnd set= A'H * 

and not" sot= AMD 'lOT * 

011= :;F.TAILEr* . 

USEH:: 



St out suny 

, USER: : 
1 i St table out 



SUNY MEDLINE RESPONSE TRANSLATION TABLE 



SS (jL) PSTG < 168 ) =Connect ion corplnted.* < 

SS (=7our -search resulted in set* 

pr<OC: = SUr;Y/rEDLi;:E:*' 

I ISSKIG lOUSLC-^UOTE !'ARK = * 

I EDTGT05 = CO':rT* 

f.r/ST 5YSTEf.=su:)Y/rEnLiME* :.. 

) PSK; (= v/liicli contains th'is mnny documents: (* 
/C?= is nunijer for your next sear'cli set.* 




+ = : * 



USER: : 
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APPE^7DIX D 

SUGGESTED USER PROTOCOLS FOR ACCESS TO A COMPUTER SYSTEM VIA A NEtWOW 

It is noted th^t a bibliographic retrieval systeip is- frequently 
accessed through networks that also provide access to other retrijeval 
systems and systems providing service in other application areas. In 
this appendix we suggest some procedures by which networked access tio 
retrieval systems and other systems may be standardized for users. 

We start from the assumption that access to several current biblio 
graphic systems should require only two pieces of i-nformation from^ the 
user: nam.e of service desired and user's password, v^hich 'implies his 
identification. An attempt has been made in the suggested protocols to 
be be co.-npatible with, or adaptable to, different terminal types, more 
general functional requirements. (other than access, per se ) in the re- 
trieval application, more general application areas, and developing 
common or virtual system approaches. 

The "standards" we propose need not imply a system must have all 
fuhctions to be -standard. Rather, they say, for example: an EXPU^.IN 
function may be a good facility to have and^ if you*^have it, -here is 
the standard way it should appear to the user.' Similarly, on request 
for service: if the' service is implied by the physical connection, there 
IS no need to insist on the request;, but if there is a request, here is 
the standard protocol'. 




-159- 



PROTOCOLS 

f 

System (Network) Acknowledgement and Service Request (After estab- . 
. lishment of telepHorfe connections and terminal speed and type 
identification) * . ' 

HELPFUL NErnvORK 13:45 EST 76-1-31 (617) 964-2007 

' (5) 
REMEMBER NEV7 PHONE NUMBERS NOW AVAILABLE/ 

TYPE N^J^2^ OF SERVICE YOU WANT (FOLLOWED BY CARRIAGE RETURN) ^"^^ : : 

^ . NOTES 



(1) Name of acknowledging^ system given here. Encourage client systems 
of networks to -.allow this (or at least some identifying phrase) 

to make it easier for user (and system analysts) to know what's 
going on^ ' * 

(2) , Time 

,(3) Date '*Standard" -- year-month-day — order ysed; however, it 
should not be necessary to force non-suppressed zeros on user 
if hyphens are given^as separators) . 

(4) This IS telephone number of port connection and can serve as' 
check for caller and as useful debugging device to identify * 
bad lines, modems, etc* Alternate form: BOSTON PORT 7. 

(5) Optiorial .system message of day. 

(6) "TYPE'Ms more explicit than, e.g., "ENTER". 

(7) This phrase may be needed for 'inexperienced liser if good 
timeout and recovery is not available (see below) . If NEW 
LINE becomes established irivplace of carriage return, some 
change will be needed. 

(8) System^ signal is two colons followed by carria^% return. 
(See Section, 4. 3) 

Service Request Response (by User) . ^ 

(1) * , ' 

orlog J 

- ^ > 1' , 

NOTES 



(1) Name of -service given here. 

(2) User responses should be allowed in either upper or lower or 
mixed alphabetic cas^s . 
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3. Service System Ac^rx>wl^(jgr.ent 'and Password Request \ 

THIS- IS MDRLOG ' \, ' ^. \ — • • 

' ( n ) ' , ' 

TYPE YOUR PASSWORD: : • J '\ \ !. . ■ 

NOTES " , ^ ' . 



(2:) ^ We assume entry df a, correct service name by user causes 
' co;itrol'to be pas^e^'d to service .system, ' " - 



(2) W-e^ assume 'here a non-cr-int ,mode ' i^ now entered for pass- 
word security, If^nor-print mode is not ^VailabfeT^' the 
form^'t would-be: - • 

•TYPE' YOUK PASS^vMiRfii ' ' • , , . • 

: : YOUR PASfeWOto - ' " • ^ ^ * 

^ .The ty/p colons would be the -l^st part of' the mes.sage and 
'the next 'typing position to 'the immediate ri;ght' o^ the ' , 

^ , colbjis which is» the first character in a .string of under- 
printing characters which mask.' the password, fhe under- 
printing «trin^ 'would st^rt.wi'th the string" "YOUR FA5SW0J^D"\ r 
and be overprinted ty tw6 or mo2;e additional lines 'to assure, 
masking (thi's device worf;&'r!s?ell on yUL'if ICS) , . ' ^ , 

' ' ' ' ' ' ''-^ ' y /\ 

Service System. Password. Acknowlejjgmpn^ . i \ \ ^. , ' ^ 

Welcome to ORLOG~... ^ " - , \ , . , 

' NOTE " " ' < / 

This message implies acceptance of password/ * ' ' . 

■ • \ ■ 

Alternate Mylti,statement Request Response tUsfe^/jgystenl) 

login orlog ^"^^ :: pass xxxxx select ' eri'c £ind'..-^/^' 



NOTES " " 



(1) /'login'* (synonyms: log or 1) is "command name- whicB'^e*!!^--,- - 
system >that user vahts to get out pf resjponse-iimiteS' mode 
and string together several. compbn,ents^ 'o'f ac.dears pr6<iedure 

' in one statement. . ' „ • • ^ . T*- - 

(2) First argument is' s-ervice neune (But s^ee' (4)) ^ 
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(3) hs an exception to general rule for user/system signals/ 
•two colQjis (no carriage return) are sent by*system to 

indicat'e that service name is recogniked and control 
passed 5n. Possibly/ this signal could be eliminated in 
a variant- cpmmand). say ""logon." V ^ 

(4) Second argument (synonyms "password" 'or "p") indicates 

. next word 'is password. This argument could be assumed . 
by content' but an explicit indication might be easier 
to imp]?ement; in the more generd'l system-tb-system inter- 
connections. . For the same reason it might be better to 
insist on an identifying 'argument (say' "service") pre- 
/ ceding service name. 

($j Password with appropriate non-print or non-print or other 
Security measures. Security measures should probably be 
responsibility of network. 

(6) ' Optional^ additional commands seijt to service system. , " 
> , NOTE: All user input after service name would be passed 
along to service system and allow for indefinitely 
long "batch" operations. , * " . 

Error Messi^ge: Invalid Serv3.ce Name * 

ORLOX is'^not a^ valid service name. If you want to see list'of 
availalple services, type LIST; otherwise, type name of service 



NOTES : 



(1) Ingorrect service name feedbact^^to user.. 

• >^ — — ^ 

(2) This CAI option should be allowed where knowleHge" Qrf"S'ervices 
is not restr^icted. 

<1') (1) 
ORLOX is the third ' successive invalid service natne we -have 

received. Call HELPFUL NETWORK representative for help at ;txx-xxxx^^ 

Your terminal connection is now being dropped . 

* ' NOTES 

(1) Three strikes and you're out I * 

(2) ' Telephone nqmber to call for iielp.v 

(3) 'T^ll user he's being disconnected. 



• ^' -162- 




170 



^ ^ ^ • D-5 



Error Message; Invalid Password 

Incorrect passwor.d received. To see what was 'received, type ECHO^^^ 
otherwise, re-type pas^ord: : 

NOTE 

(1) This option should be avaiTable when user can accept lack 
of security in printing of near-password. 

Error flessage: Repeated Invalid Password 

Incorrect pa^v/ord received three successive times. Call your ORLOG 
representative for^ help at xxx-xxxx. You are being returned to 
HELPFUL NETWORK. [Followed by Message 1.] 

Timeout Message 

No response received in 2 minutes. Call HELPFUL NETVORK representative 
if you need help: xxx-xxxx. Your terminal connection is now being 
dropped. ' • 



>Exit Commands 
11. a login helpful^ 



NOTE 



This means that the user wan^ts to leave service system (after appro- 
priate exit and accounting messfages) and return (or login) to system 
indicated. This -may require passing appropriate information to other 
systems. Default cpndition (no argument: synonym EXIT) would mean 
drop back to calling system. 

fl.b Logout.' 

NOTE 

\ 

This means user wants to stop altogether and have his terminal dis- 
.<5onnected. Logout is the natural antonym for lo gin . 

Edit Commands 

12. a Cancel m preceding characters: m "left arrows". 



171 
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NOTES 

(1) Buffered terminals can replace deleted characters 

(2) Is It important to use an ASCII character? 

12. b Cancel line: @ (m at-signs would mean cancel last m lines) 
Interrupt 

Requested through special button (normally activating a line-condition 
change rather than a character — called INTERRUPT, ATTENTION ,„ QUIT , 
etc.), a very important function, especially on system output where 
It means "stop output, give system signal, and allow user input." 
On user input it can be used instead of cancel line (system signal 
invoked) . 

CM Commands 

1 

14. a Explain x (synonym: exp) . . [ 

Argument may be message name or word in messa^ge, for example.' 
May be useful even in access procedures, as in "explain ser- 
vice" v/hich might, along with some other explanation, do same 
as "list" (see (6)). Default condition: e;:plain last system' 
' message further. 

14. b Help (synonym: ?) . 

Generalized CAI for current context; i.e., what current user 
options are and how to get further infonnatior cn those options. 



17^ 
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